[Freeipa-users] RHEL 5.7 / 5.8 BETA and KDE crashing SSSD

[Sigbjorn Lie]

On 02/04/2012 02:58 PM, Stephen Gallagher wrote:
> On Fri, 2012-02-03 at 12:53 +0100, Sigbjorn Lie wrote:
>> On Wed, February 1, 2012 15:04, Simo Sorce wrote:
>>> On Wed, 2012-02-01 at 07:28 -0500, Stephen Gallagher wrote:
>>>
>>>> On Wed, 2012-02-01 at 11:02 +0100, Sigbjorn Lie wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>> Is this more like the expected output? :)
>>>>>
>>>>>
>>>> No, I'm afraid it's not. That's a log of a legitimate shutdown, not a
>>>> segmentation fault. (Receiving SIGTERM means that the monitor told the process to exit).
>>>>
>>>> Possibly this happened if the time between attaching to the process and
>>>> typing 'cont' was more than about 30 seconds. The monitor will assume the sssd_be process isn't
>>>> responding and will kill and restart it.
>>>>
>>>> You will know you got the correct results if you see
>>>>
>>>>
>>>> "Program received signal SIGSEGV, Segmentation fault."
>>>>
>>>>
>>>> and then you can immediately perform the 'bt full'
>>> For better results with gdb I suggest to kill SIGSTOP the monitor before
>>> attaching gdb to any of the reponders or the providers, this way the monitor will be prevented from
>>> sending termination signals to the children. However, don't do this for long, only for short
>>> periods and kill SIGCONT back the monitor immediately after.
>>>
>>>
>> Please see below. Does this help?
> Yes, thank you it does.
>
>>
>> (gdb) bt full
>> #0  sysdb_attrs_get_el_int (attrs=0x6c616d726f6e2d72, name=0x43c75d "name",
>>      alloc=true, el=0x7fffe9e0dab8) at src/db/sysdb.c:254
>>          e =<value optimized out>
>>          i =<value optimized out>
>> #1  0x00000000004221d7 in sysdb_attrs_primary_name (sysdb=0xf725e00,
>>      attrs=0x6c616d726f6e2d72, ldap_attr=0xf741110 "cn",
> The memory address for "attrs" here is WAY out of range. That suggests
> that this is an uninitialized value.
>
>>      _primary=0x7fffe9e0db58) at src/db/sysdb.c:2441
>>          ret =<value optimized out>
>>          rdn_attr = 0x0
>>          rdn_val = 0x0
>>          sysdb_name_el = 0x61
>>          orig_dn_el =<value optimized out>
>>          i =<value optimized out>
>>          tmpctx = 0xf768ce0
>>          __FUNCTION__ = "sysdb_attrs_primary_name"
>> #2  0x000000000042290d in sysdb_attrs_primary_name_list (sysdb=0xf725e00,
>>      mem_ctx=<value optimized out>, attr_list=0xf772e20, attr_count=2,
>>      ldap_attr=0xf741110 "cn", name_list=0x7fffe9e0dc88) at src/db/sysdb.c:2606
>>          ret = 259427552
>>          i = 1
> i = 1, so it's the second entry in the attr_list being passed in. My
> spidey-sense is tingling here. Probably the array is one entry too long
> above.
>
>>          j = 1
>>          list =<value optimized out>
>>          name = 0xf769580 "ac_server-normal"
>>          __FUNCTION__ = "sysdb_attrs_primary_name_list"
>> #3  0x00002b20c9684456 in sdap_initgr_nested_get_membership_diff (
>>      state=0xf7726f0) at src/providers/ldap/sdap_async_accounts.c:3061
>>          __FUNCTION__ = "sdap_initgr_nested_get_membership_diff"
>
> This is the function that is creating that array (well, actually it's
> sdap_initgr_nested_get_direct_parents()). So the bug must be occurring
> here. We're somehow creating an array of two entries but not populating
> the second one.
>
> That said, I'm not sure how that's possible. The code there is very
> short and seems pretty carefully-written to avoid this possibility.
>
> I don't have time today to dig into this any further, but I wanted to
> get my findings down in an email so that if anyone else wanted to jump
> on this before I get back to it, they don't have to start from scratch.

Is there anything further I can do to help out troubleshooting this issue?

I have opened a case (case id 00594772) and referenced this thread, as 
this issue occurred at a paying customers site.


Regards,
Siggi