On 02/04/2012 02:58 PM, 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:
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
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
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.
Is there anything further I can do to help out troubleshooting this issue?
I have opened a case (case id 00594772) and referenced this thread, as
this issue occurred at a paying customers site.
Freeipa-users mailing list