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-389-ds-base-1.3.2.21-1.fc20-crashed-ove.patch
Test case: https://fedorahosted.org/389/attachment/ticket/47871/0002-Ticket-47871-Test-case-389-ds-base-1.3.2.21-1.fc20-c.patch
Thanks
thierry
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
|
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
