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:
The test case you provide looks like it is testing that changelog
trimming is working, shouldn't the test case for the ticket produce
the crash it fixes (or does it and I missed it) ?
On 08/21/2014 03:40 PM, thierry bordaz wrote:
> Ticket
https://fedorahosted.org/389/ticket/47871
> Fix:
>
https://fedorahosted.org/389/attachment/ticket/47871/0001-Ticket-47871-38...
> Test case:
>
https://fedorahosted.org/389/attachment/ticket/47871/0002-Ticket-47871-Te...
>
> Thanks
> thierry
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel