On Wed, 2012-02-08 at 12:23 +0100, Sigbjorn Lie wrote: > 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?
We haven't forgotten about you, but we've been tied up dealing with the 1.8 beta. We're starting to look at the backlog of bugs now.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Freeipa-users mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
