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

[Sigbjorn Lie]

On Sat, February 4, 2012 14:58, 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.


Hi,

Any progress on this?


Regards,
Siggi