Hi Ludwig,

You are right, the test case only checks that trimming is still working :-[ .

The problem is that the failing thread ends with an invalid pointer and SIGSEV.
I imagine two possibilities:

• The thread dereference a pointer that is not a valid address.
  The stacktrace makes think we are in that case. The pointer is said to be e=0x105.
  Now I do not understand how this can occur because this pointer is an entry returned from an internal search so it should be an address on the heap.
  This pointer value is displayed as arg of slapi_entry_attr_find but can not be retrieve from the calling function. So I am unsure if the displayed value was the effective value.
  

  Thread 1 (Thread 0x7f83a2cb2700 (LWP 30103)):
  #0  attrlist_find (a=0x105, type=0x7f8395818716 "changetime") at ldap/servers/slapd/attrlist.c:144
  No locals.
  #1  0x00007f83a286bec2 in slapi_entry_attr_find (e=0x105, type=0x7f8395818716 "changetime", a=0x7f83a2cb1d58) at ldap/servers/slapd/entry.c:2362
          r = 1547436624
  #2  0x00007f83958176b0 in trim_changelog () at ldap/servers/plugins/retrocl/retrocl_trim.c:287
          sval = 0x0
          val = 0x0
          did_delete = 0
          attr = 0x0
          ldrc = <optimized out>
          me = 172800
          done = 0
          e = <optimized out>

  If the value returned by internal search was 0x105, then I think an error (heap corruption ?) occurred down in the internal search and the current stacktrace can not help us to find it.
  
  
• The thread dereference a pointer that is no longer allocated.
  
  This is the purpose of this fix as we know that the returned entry was accessed outside of the callback function, where the entry has been freed.
  This fix has no test case because to trigger the crash the entry must be freed/allocated before the trimming thread access it.
  
  

The fix changed the trimming algo so the test case I made was to verify that the trimming was still working.
Martin explained me that the crash occurred while there was no ldap client activity. I will then setup some test machines, run the freeipa acceptance and let them idle other the week end. I will run one machine without the fix and the others with the fix. Also I will reduce the timming period.

thanks
thierry

On 08/21/2014 04:23 PM, Ludwig Krispenz wrote: