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 _______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users