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.

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to