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.
Description: This is a digitally signed message part
_______________________________________________ Freeipa-users mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-users