[389-devel] Please review Ticket 47871: 389-ds-base-1.3.2.21-1.fc20 crashed over the weekend

[thierry bordaz]

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 at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
>
>
> --
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-devel/attachments/20140822/0e3c1fde/attachment.html>