4:07 p.m.
Oops, hit reply instead of reply-all
NSPR RPMs
# yum list installed nspr*
Installed Packages
nspr.armv7hl
4.19.0-1.fc27
@updates
nspr-debuginfo.armv7hl
4.19.0-1.fc27
@updates-debuginfo
nspr-debugsource.armv7hl
4.19.0-1.fc27
@updates-debuginfo
nspr-devel.armv7hl
4.19.0-1.fc27
@updates
As for building it with the changes you proposed previously - should I not
bother? I realized last night that the last and only time I built anything
*on* a Pi was a Pi Zero and that's why it was so terribly slow. This Pi 3
ain't fast but it's fast enough to build stuff in far less than half a day
(unlike the Zero)...
On Thu, May 17, 2018 at 5:07 AM, thierry bordaz <tbordaz(a)redhat.com> wrote:
On 05/16/2018 10:03 PM, Jonathan Vaughn wrote:
I've been just using the packages from Fedora. I can build it potentially
but I don't have a cross build environment set up at the moment. From
experience I'd want to do that first because building anything on the Pi
usually takes ages.
I'd been "redacting" the hostnames but I'll stop bothering since it
looks
like we're getting far enough into the weeds now that the difference in
string lengths after "redacting" might actually be a red herring.
(gdb) p *agmt
$1 = {hostname = 0x1ef9be0 "ipa-12.creatuity.internal", port = 389,
transport_flags = 0, binddn = 0x1e8f650 "", creds = 0x1e8f7a0, bindmethod =
3, replarea = 0x1ef9480,
frac_attrs = 0x1ef99c0, frac_attrs_total = 0x1ef9a40,
frac_attr_total_defined = 1, schedule = 0x1a7f0c0, auto_initialize = 502,
dn = 0x1ef8d00, rdn = 0x1ef8c20,
long_name = 0x1a7f100 "agmt=\"cn=meToipa-12.creatuity.internal\"
(ipa-12:5)", protocol = 0x19c2930, changecounters = 0x186d180,
num_changecounters = 0,
max_changecounters = 256, last_update_start_time = 1526500697,
last_update_end_time = 1526500697,
last_update_status = "Error (0) Replica acquired successfully:
Incremental update succeeded", '\000' <repeats 954 times>,
update_in_progress = 0, is_enabled = 1,
last_init_start_time = 0, last_init_end_time = 0, last_init_status =
'\000' <repeats 1023 times>, lock = 0x1ee3740, consumerRUV = 0x1f14e50,
consumerSchemaCSN = 0x317c520, consumerRID = 4, tmpConsumerRID = 0,
timeout = 120, stop_in_progress = 0, busywaittime = 0, pausetime = 0, priv
= 0x0,
attrs_to_strip = 0x1ef9ba0, agreement_type = 0, protocol_timeout =
0x1e8f5f0, maxcsn = 0x0, flowControlWindow = 1000, flowControlPause = 2000,
ignoreMissingChange = 0,
attr_lock = 0x1ef9c20, WaitForAsyncResults = 100}
(gdb) p *agmt->replarea
$2 = {flag = 15 '\017', udn = 0x1efce80 "dc=creatuity,dc=internal", dn
=
0x1ef9460 "dc=creatuity,dc=internal", ndn = 0x1ef8ec0
"dc=creatuity,dc=internal", ndn_len = 24}
(gdb) p *agmt->rdn
$3 = {flag = 0 '\000', rdn = 0x19c2840
"cn=meToipa-12.creatuity.internal",
rdns = 0x0, butcheredupto = -1, nrdn = 0x0, all_rdns = 0x0, all_nrdns = 0x0}
[root@ipa-11 ~]# grep -r PRId64 /usr/include/*
/usr/include/inttypes.h:# define PRId64 __PRI64_PREFIX "d"
[root@ipa-11 ~]# grep -r PRIu16 /usr/include/*
/usr/include/inttypes.h:# define PRIu16 "u"
On Wed, May 16, 2018 at 2:55 PM, Mark Reynolds <mreynolds(a)redhat.com>
wrote:
>
>
> On 05/16/2018 03:43 PM, Jonathan Vaughn wrote:
>
> The installed version of 389* is 1.3.7.10-1.fc27 for armv7hl, which
> appears to be the latest available version.
>
>
> Perhaps something is off with the inttypes on Raspberry. Are you
> building this yourself on Raspberry? Can we make code changes and
> compile/install them?
>
> Before we do that though, in gdb can you run these commands in the same
> gdb frame:
>
> (gdb) p *agmt->replarea
> (gdb) p *agmt->rdn
>
>
> Then do:
>
> # grep -r PRId64 /usr/include/*
> # grep -r PRIu16 /usr/include/*
>
>
> So if you can compile the source, then change this line in
> ldap/servers/plugins/replication/repl5_agmt.c:3036, but don't do this
> yet until you get me the info I just requested.
>
> From:
>
> agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%" PRId64
";%"
> PRIu16 ";%s", slapi_sdn_get_dn(agmt->replarea),
>
> slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
> agmt->port,
> agmt->consumerRID, maxcsn);
>
> To:
>
> agmt->maxcsn = slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
> slapi_sdn_get_dn(agmt->replarea),
>
> slapi_rdn_get_value_by_ref(slapi_rdn_get_rdn(agmt->rdn)), agmt->hostname,
> (long)agmt->port,
> (int)agmt->consumerRID, maxcsn);
>
>
> Thanks,
> Mark
>
>
> On Wed, May 16, 2018 at 2:38 PM, Jonathan Vaughn <jonathan(a)creatuity.com>
> wrote:
>
>
The agreement structure looks valid to me. it should not lead to a crash.
What looks weird to me is the order of the arguments of cvt_s.
It is called: rv = cvt_s(ss, u.s, width, prec, flags);
But the crashing thread shows the opposite order: flags, prec,width, str,
ss
The others frame do not show this change of order.
Also 'str=4' that would be a meaningful value for 'prec=4'.
From debug perspective I only imagine disassemble the two last frames to
confirm parameters.
What are the nspr rpms ?
(gdb) up
>> #1 0xb6926b40 in cvt_s (flags=0, prec=<optimized out>, width=0, str=0x4
>> <error: Cannot access memory at address 0x4>, ss=<optimized out>)
>> at ../../.././nspr/pr/src/io/prprf.c:374
>> 374 slen = strlen(str);
>> (gdb) up
>> #2 dosprintf (ss=ss@entry=0x9e06e4bc, fmt=0xb34b0df2 "",
fmt@entry=0xb34da770
>> <agmt_set> "\360\317p\002", ap=...) at
../../.././nspr/pr/src/io/prpr
>> f.c:1018
>> 1018 rv = cvt_s(ss, u.s, width, prec, flags);
>> (gdb) up
>> #3 0xb6926c8c in PR_vsmprintf (fmt=fmt@entry=0xb34da770 <agmt_set>
>> "\360\317p\002", ap=..., ap@entry=...) at
../../.././nspr/pr/src/io/prpr
>> f.c:1184
>> 1184 rv = dosprintf(&ss, fmt, ap);
>> (gdb) up
>> #4 0xb6de9d18 in slapi_ch_smprintf (fmt=0xb34b0de0
>> "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c:331
>> 331 p = PR_vsmprintf(fmt, ap);
>> (gdb) up
>> #5 0xb34625a4 in agmt_update_maxcsn (r=r@entry=0x2737810,
>> sdn=0x38d9a40, sdn@entry=0x10, op=<optimized out>, mods=0x10,
mods@entry=0x27d0100,
>> csn=csn@entry=0x38de350)
>> at ldap/servers/plugins/replication/repl5_agmt.c:3036
>> 3036 agmt->maxcsn =
slapi_ch_smprintf("%s;%s;%s;%ld;%d;%s",
>> slapi_sdn_get_dn(agmt->replarea),
>> (gdb) p *agmt
>> $1 = {hostname = 0x2757be0 "ipa-12.company.internal", port = 389,
>> transport_flags = 0, binddn = 0x26ed650 "", creds = 0x26ed7a0,
bindmethod =
>> 3, replarea = 0x2757480,
>> frac_attrs = 0x27579c0, frac_attrs_total = 0x2757a40,
>> frac_attr_total_defined = 1, schedule = 0x22dd0c0, auto_initialize = 502,
>> dn = 0x2756d00, rdn = 0x2756c20,
>> long_name = 0x22dd100 "agmt=\"cn=meToipa-12.company.internal\"
>> (ipa-12:5)", protocol = 0x2220930, changecounters = 0x20cb180,
>> num_changecounters = 0,
>> max_changecounters = 256, last_update_start_time = 1526499214,
>> last_update_end_time = 1526499214,
>> last_update_status = "Error (0) Replica acquired successfully:
>> Incremental update succeeded", '\000' <repeats 954 times>,
>> update_in_progress = 0, is_enabled = 1,
>> last_init_start_time = 0, last_init_end_time = 0, last_init_status =
>> '\000' <repeats 1023 times>, lock = 0x2741740, consumerRUV =
0x2772e50,
>> consumerSchemaCSN = 0x39da520, consumerRID = 4, tmpConsumerRID = 0,
>> timeout = 120, stop_in_progress = 0, busywaittime = 0, pausetime = 0, priv
>> = 0x0,
>> attrs_to_strip = 0x2757ba0, agreement_type = 0, protocol_timeout =
>> 0x26ed5f0, maxcsn = 0x0, flowControlWindow = 1000, flowControlPause = 2000,
>> ignoreMissingChange = 0,
>> attr_lock = 0x2757c20, WaitForAsyncResults = 100}
>>
>>
>> On Tue, May 15, 2018 at 5:36 PM, Mark Reynolds <mreynolds(a)redhat.com>
>> wrote:
>>
>>> This looks really familiar and I thought it was fixed. It should have
>>> been fixed in 1.3.7.10-1 (https://pagure.io/389-ds-base/issue/49618).
>>> In your debug session go "up" into agmt_maxcsn_update() and do:
>>>
>>> (gdb) p *agmt
>>>
>>> Then send us that output please.
>>>
>>> Thanks,
>>> Mark
>>>
>>>
>>> On 05/15/2018 05:29 PM, Jonathan Vaughn via FreeIPA-users wrote:
>>>
>>> Here is a backtrace from live gdb after the segfault. Looks like things
>>> went wrong somewhere during in the replication code ?
>>>
>>> Thread 36 "ns-slapd" received signal SIGSEGV, Segmentation fault.
>>> [Switching to Thread 0x9e0bc280 (LWP 4662)]
>>> strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
>>> 142 ldrd data1a, data1b, [src]
>>> (gdb) bt
>>> #0 0xb6728f2e in strlen () at ../sysdeps/arm/armv6t2/strlen.S:142
>>> #1 0xb6973b40 in cvt_s (flags=0, prec=<optimized out>, width=0,
>>> str=0x4 <error: Cannot access memory at address 0x4>, ss=<optimized
out>)
>>> at ../../.././nspr/pr/src/io/prprf.c:374
>>> #2 0xb6973b40 in dosprintf (ss=ss@entry=0x9e0bb4bc, fmt=0xb34fddf2
>>> "", fmt@entry=0xb3527770 <agmt_set>
"\360\357\305\002", ap=...)
>>> at ../../.././nspr/pr/src/io/prprf.c:1018
>>> #3 0xb6973c8c in PR_vsmprintf (fmt=fmt@entry=0xb3527770 <agmt_set>
>>> "\360\357\305\002", ap=..., ap@entry=...) at
>>> ../../.././nspr/pr/src/io/prprf.c:1184
>>> #4 0xb6e36d18 in slapi_ch_smprintf (fmt=0xb34fdde0
>>> "%s;%s;%s;%ld;%d;%s") at ldap/servers/slapd/ch_malloc.c:331
>>> #5 0xb34af5a4 in agmt_update_maxcsn (r=r@entry=0x2c89810,
>>> sdn=0x3e2bac0, sdn@entry=0x10, op=<optimized out>, mods=0x10,
>>> mods@entry=0x3eec100, csn=csn@entry=0x3e30220)
>>> at ldap/servers/plugins/replication/repl5_agmt.c:3036
>>> #6 0xb34bd424 in write_changelog_and_ruv (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/plugins/replication/repl5_plugins.c:1124
>>> #7 0xb34be7ec in multimaster_be_betxnpostop_add (pb=0x2cb54a0) at
>>> ldap/servers/plugins/replication/repl5_plugins.c:855
>>> #8 0xb34be880 in multimaster_mmr_postop (pb=<optimized out>,
>>> flags=560) at ldap/servers/plugins/replication/repl5_plugins.c:616
>>> #9 0xb6e8fcf0 in plugin_call_mmr_plugin_postop (pb=pb@entry=0x2cb54a0,
>>> e=e@entry=0x0, flags=flags@entry=560) at ldap/servers/slapd/plugin_mmr.
>>> c:65
>>> #10 0xb35ba870 in ldbm_back_add (pb=0x2cb54a0) at
>>> ldap/servers/slapd/back-ldbm/ldbm_add.c:1218
>>> #11 0xb6e2ce4c in op_shared_add (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:679
>>> #12 0xb6e2d35c in add_internal_pb (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:407
>>> #13 0xb6e2e0f8 in slapi_add_internal_pb (pb=pb@entry=0x2cb54a0) at
>>> ldap/servers/slapd/add.c:332
>>> #14 0xb368db50 in ipa_topo_util_segment_write (tconf=tconf@entry=0x2cb5860,
>>> tsegm=tsegm@entry=0x3f2d9a0) at topology_util.c:1251
>>> #15 0xb368e01c in ipa_topo_util_update_agmt_list (conf=0x2cb5860,
>>> repl_segments=<optimized out>) at topology_util.c:696
>>> #16 0xb368891c in ipa_topo_apply_shared_config () at topology_init.c:165
>>> #17 0xb6e4e65c in eq_call_all () at ldap/servers/slapd/eventq.c:278
>>> #18 0xb6e4e65c in eq_loop (arg=<optimized out>) at
>>> ldap/servers/slapd/eventq.c:323
>>> #19 0xb6982d68 in _pt_root (arg=0x2c8da40) at
>>> ../../.././nspr/pr/src/pthreads/ptthread.c:201
>>> #20 0xb6906ee8 in start_thread (arg=0x9e0bc280) at pthread_create.c:465
>>> #21 0xb6785da8 in None () at ../sysdeps/unix/sysv/linux/arm/clone.S:73
>>>
>>>
>>> On Tue, May 15, 2018 at 3:01 AM, thierry bordaz <tbordaz(a)redhat.com>
>>> wrote:
>>>
>>>> Hi Jonathan,
>>>>
>>>> This problem looks new to me and has something specific to your
>>>> environment.
>>>> I think the best approach is to continue to debug on your system if
>>>> you have the possibility to do so.
>>>>
>>>> From strace we can see that DS started smoothly (created its pid file
>>>> then notified systemd it was running fine). According to the pstack
>>>> nunc-stans was running and was able to accept network events even if it
>>>> appears it detected no incoming connection.
>>>> So the server should be ready to serve for some seconds (more than a
>>>> minute), then it crashed with one thread dereferencing likely a wrong
>>>> pointer.
>>>>
>>>> Could you attach a debugger when the server is started and wait for
>>>> the sigsegv to occur. Then confirm the crashing thread backstack.
>>>> If it is confirmed, I am afraid this is a stack corruption and
>>>> valgrind could help (http://www.port389.org/docs/3
>>>> 89ds/FAQ/faq.html#debugging-memory-growthinvalid-access-with-valgrind
>>>> ).
>>>>
>>>> best regards
>>>> thierry
>>>>
>>>>
>>>> On 05/14/2018 10:20 PM, Jonathan Vaughn wrote:
>>>>
>>>> Here's a strace from before it dies. Most of the elapsed time is it
>>>> waiting on some futex call it looks like near the end, when it finally
>>>> "returns" (from lack of strace output for duration of call I
assume it
>>>> didn't actually return but SIGSEGV in that call) and strace prints
' = ?'
>>>> on the futex it then immediately reports SIGSEGV after. So maybe the
>>>> problem is that futex call, which may mean the problem is not directly
in
>>>> 389DS / FreeIPA itself?
>>>>
>>>>
>>>>
>>>> 15:13:31.626587 (+ 0.000630) listen(8, 128) = 0 <0.000068>
>>>> 15:13:31.626857 (+ 0.000235) listen(9, 128) = 0 <0.000048>
>>>> 15:13:31.627111 (+ 0.000251) clock_gettime(CLOCK_MONOTONIC,
>>>> {tv_sec=1464932, tv_nsec=41120614}) = 0 <0.000085>
>>>> 15:13:31.627457 (+ 0.000356) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=627560772}) = 0 <0.000043>
>>>> 15:13:31.631233 (+ 0.003839) clock_gettime(CLOCK_MONOTONIC,
>>>> {tv_sec=1464932, tv_nsec=45286796}) = 0 <0.000077>
>>>> 15:13:31.631720 (+ 0.000427) clock_gettime(CLOCK_MONOTONIC,
>>>> {tv_sec=1464932, tv_nsec=45661430}) = 0 <0.000042>
>>>> 15:13:31.631955 (+ 0.000220) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=632049036}) = 0 <0.000047>
>>>> 15:13:31.635669 (+ 0.003785) clock_gettime(CLOCK_MONOTONIC,
>>>> {tv_sec=1464932, tv_nsec=49725840}) = 0 <0.000146>
>>>> 15:13:31.636484 (+ 0.000784) write(16, "a", 1) = 1
<0.000118>
>>>> 15:13:31.636855 (+ 0.000341) sched_yield() = 0 <0.000252>
>>>> 15:13:31.637322 (+ 0.000470) futex(0x1cb57a0, FUTEX_WAKE_PRIVATE,
>>>> 1) = 1 <0.000088>
>>>> 15:13:31.637897 (+ 0.000610) write(16, "a", 1) = 1
<0.000221>
>>>> 15:13:31.638394 (+ 0.000467) sched_yield() = 0 <0.000047>
>>>> 15:13:31.638619 (+ 0.000202) futex(0x1cb5710, FUTEX_WAKE_PRIVATE,
>>>> 1) = 1 <0.000065>
>>>> 15:13:31.638908 (+ 0.000298) openat(AT_FDCWD,
>>>> "/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
>>>> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 33 <0.000831>
>>>> 15:13:31.640260 (+ 0.001387) getpid() = 32353 <0.000077>
>>>> 15:13:31.640558 (+ 0.000256) fstat64(33, {st_mode=S_IFREG|0644,
>>>> st_size=0, ...}) = 0 <0.000119>
>>>> 15:13:31.641106 (+ 0.000556) write(33, "32353\n", 6) = 6
<0.000127>
>>>> 15:13:31.641472 (+ 0.000362) close(33) = 0 <0.000519>
>>>> 15:13:31.642216 (+ 0.000758)
chmod("/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
>>>> 0644) = 0 <0.000152>
>>>> 15:13:31.642900 (+ 0.000679) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=643020294}) = 0 <0.000056>
>>>> 15:13:31.643495 (+ 0.000590) write(2,
>>>> "[14/May/2018:15:13:31.643020294 "..., 134) = 134
<0.002697>
>>>> 15:13:31.646515 (+ 0.003052) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=646694394}) = 0 <0.000075>
>>>> 15:13:31.646892 (+ 0.000337) write(4,
>>>> "[14/May/2018:15:13:31.646694394 "..., 134) = 134
<0.000522>
>>>> 15:13:31.647841 (+ 0.000973) fsync(4) = 0 <0.005967>
>>>> 15:13:31.654425 (+ 0.006617) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=654598946}) = 0 <0.000253>
>>>> 15:13:31.655137 (+ 0.000717) write(2,
>>>> "[14/May/2018:15:13:31.654598946 "..., 136) = 136
<0.002427>
>>>> 15:13:31.658312 (+ 0.003165) clock_gettime(CLOCK_REALTIME,
>>>> {tv_sec=1526328811, tv_nsec=658486117}) = 0 <0.000251>
>>>> 15:13:31.659032 (+ 0.000682) write(4,
>>>> "[14/May/2018:15:13:31.658486117 "..., 136) = 136
<0.000346>
>>>> 15:13:31.659623 (+ 0.000595) fsync(4) = 0 <0.003311>
>>>> 15:13:31.663230 (+ 0.003642) getpid() = 32353 <0.000045>
>>>> 15:13:31.663732 (+ 0.000454) socket(AF_UNIX,
>>>> SOCK_DGRAM|SOCK_CLOEXEC, 0) = 33 <0.000296>
>>>> 15:13:31.664760 (+ 0.001048) getsockopt(33, SOL_SOCKET, SO_SNDBUF,
>>>> [163840], [4]) = 0 <0.000108>
>>>> 15:13:31.665141 (+ 0.000386) setsockopt(33, SOL_SOCKET,
>>>> SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not permitted)
>>>> <0.000051>
>>>> 15:13:31.665500 (+ 0.000334) setsockopt(33, SOL_SOCKET, SO_SNDBUF,
>>>> [8388608], 4) = 0 <0.000229>
>>>> 15:13:31.665973 (+ 0.000468) sendmsg(33,
>>>> {msg_name={sa_family=AF_UNIX, sun_path="/run/systemd/notify"},
>>>> msg_namelen=21, msg_iov=[{iov_base="READY=1\nSTATUS=slapd started:
>>>> Re"..., iov_len=69}], msg_iovlen=1, msg_controllen=0, msg_flags=0},
>>>> MSG_NOSIGNAL) = 69 <0.000600>
>>>> 15:13:31.667270 (+ 0.001334) close(33) = 0 <0.003140>
>>>> 15:13:31.677320 (+ 0.010146) futex(0xb31122e8, FUTEX_WAIT, 32357,
>>>> NULL) = ?
>>>> 15:14:27.661809 (+ 55.984448) +++ killed by SIGSEGV (core dumped)
>>>> +++
>>>>
>>>> On Mon, May 14, 2018 at 10:27 AM, thierry bordaz
<tbordaz(a)redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Jonathan,
>>>>>
>>>>> This is weird as the crashing thread stack looks truncated (did you
>>>>> copy/paste all of it ?)
>>>>>
>>>>> Thread 1 (Thread 0x9e13c280 (LWP 17245)):
>>>>> #0 0xb67bbf2e in strlen () at /lib/libc.so.6
>>>>> #1 0xb6a06b40 in dosprintf () at /lib/libnspr4.so
>>>>> #2 0x00000000 in None ()
>>>>>
>>>>> Did you install 389-ds-base-debuginfo ?
>>>>> How did you get that backtrace ? from a core dumped, pstack ? Can
you
>>>>> attach a debugger before the crash occurs ?
>>>>>
>>>>> It looks it crashed soon at startup, could it be related to a broken
>>>>> dse.ldif. It should exists a dse.ldif.OK, is it possibly to try to
start
>>>>> with it ?
>>>>>
>>>>> best regards
>>>>> thierry
>>>>>
>>>>> On 05/12/2018 01:22 AM, Jonathan Vaughn via FreeIPA-users wrote:
>>>>>
>>>>> Not sure if it makes a difference... I was looking into this again
>>>>> and realized I had a bunch of messages from gdb telling me to install
more
>>>>> debuginfo. I've done that now, here it is again freshly run
through gdb
>>>>>
>>>>> GNU gdb (GDB) Fedora 8.0.1-36.fc27
>>>>> Copyright (C) 2017 Free Software Foundation, Inc.
>>>>> License GPLv3+: GNU GPL version 3 or later <
>>>>> http://gnu.org/licenses/gpl.html>
>>>>> This is free software: you are free to change and redistribute it.
>>>>> There is NO WARRANTY, to the extent permitted by law. Type
"show
>>>>> copying"
>>>>> and "show warranty" for details.
>>>>> This GDB was configured as "armv7hl-redhat-linux-gnueabi".
>>>>> Type "show configuration" for configuration details.
>>>>> For bug reporting instructions, please see:
>>>>> <http://www.gnu.org/software/gdb/bugs/>;.
>>>>> Find the GDB manual and other documentation resources online at:
>>>>> <http://www.gnu.org/software/gdb/documentation/>;.
>>>>> For help, type "help".
>>>>> Type "apropos word" to search for commands related to
"word"...
>>>>> Reading symbols from /usr/sbin/ns-slapd...Reading symbols from
>>>>> /usr/lib/debug/usr/sbin/ns-slapd-1.3.7.10-1.fc27.arm.debug...done.
>>>>> done.
>>>>> ...
>>>>>
>>>>> Thread 1 (Thread 0x9e13c280 (LWP 17245)):
>>>>> #0 0xb67bbf2e in strlen () at /lib/libc.so.6
>>>>> #1 0xb6a06b40 in dosprintf () at /lib/libnspr4.so
>>>>> #2 0x00000000 in None ()
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 8, 2018 at 7:52 AM, Rob Crittenden
<rcritten(a)redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Jonathan Vaughn via FreeIPA-users wrote:
>>>>>>>
>>>>>>>> Still trying to figure this out. It looks like slapd is
dying, I
>>>>>>>> thought it was still running for some reason.
>>>>>>>>
>>>>>>>> slapd is dying to segfault. strace of it happening
doesn't seem to
>>>>>>>> reveal much:
>>>>>>>>
>>>>>>>
>>>>>>> A stack trace would very much help trying to track down the
cause.
>>>>>>>
>>>>>>> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#d
>>>>>>> ebugging-crashes
>>>>>>>
>>>>>>> rob
>>>>>>>
>>>>>>>
>>>>>>>> 18:32:41.543717 (+ 0.000801) openat(AT_FDCWD,
>>>>>>>> "/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
>>>>>>>> O_WRONLY|O_CREAT|O_TRUNC, 0666) = 32
>>>>>>>> 18:32:41.544907 (+ 0.001195) getpid() = 16014
>>>>>>>> 18:32:41.545269 (+ 0.000329) fstat64(32,
>>>>>>>> {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
>>>>>>>> 18:32:41.545799 (+ 0.000536) write(32,
"16014\n", 6) = 6
>>>>>>>> 18:32:41.546603 (+ 0.000818) close(32) = 0
>>>>>>>> 18:32:41.547061 (+ 0.000448)
chmod("/var/run/dirsrv/slapd-COMPANY-INTERNAL.pid",
>>>>>>>> 0644) = 0
>>>>>>>> 18:32:41.547741 (+ 0.000676)
clock_gettime(CLOCK_REALTIME,
>>>>>>>> {tv_sec=1525735961, tv_nsec=548030641}) = 0
>>>>>>>> 18:32:41.548324 (+ 0.000587) write(2,
>>>>>>>> "[07/May/2018:18:32:41.548030641 "..., 134) =
134
>>>>>>>> 18:32:41.551096 (+ 0.002840)
clock_gettime(CLOCK_REALTIME,
>>>>>>>> {tv_sec=1525735961, tv_nsec=551287555}) = 0
>>>>>>>> 18:32:41.551568 (+ 0.000406) write(4,
>>>>>>>> "[07/May/2018:18:32:41.551287555 "..., 134) =
134
>>>>>>>> 18:32:41.552360 (+ 0.000811) fsync(4) = 0
>>>>>>>> 18:32:41.558499 (+ 0.006170)
clock_gettime(CLOCK_REALTIME,
>>>>>>>> {tv_sec=1525735961, tv_nsec=558678099}) = 0
>>>>>>>> 18:32:41.558901 (+ 0.000350) write(2,
>>>>>>>> "[07/May/2018:18:32:41.558678099 "..., 136) =
136
>>>>>>>> 18:32:41.561537 (+ 0.002680)
clock_gettime(CLOCK_REALTIME,
>>>>>>>> {tv_sec=1525735961, tv_nsec=561718659}) = 0
>>>>>>>> 18:32:41.562357 (+ 0.000793) write(4,
>>>>>>>> "[07/May/2018:18:32:41.561718659 "..., 136) =
136
>>>>>>>> 18:32:41.563293 (+ 0.001148) fsync(4) = 0
>>>>>>>> 18:32:41.566928 (+ 0.003452) getpid() = 16014
>>>>>>>> 18:32:41.567712 (+ 0.000752) socket(AF_UNIX,
>>>>>>>> SOCK_DGRAM|SOCK_CLOEXEC, 0) = 32
>>>>>>>> 18:32:41.568628 (+ 0.000912) getsockopt(32,
SOL_SOCKET,
>>>>>>>> SO_SNDBUF, [163840], [4]) = 0
>>>>>>>> 18:32:41.568972 (+ 0.000319) setsockopt(32,
SOL_SOCKET,
>>>>>>>> SO_SNDBUFFORCE, [8388608], 4) = -1 EPERM (Operation not
permitted)
>>>>>>>> 18:32:41.569548 (+ 0.000589) setsockopt(32,
SOL_SOCKET,
>>>>>>>> SO_SNDBUF, [8388608], 4) = 0
>>>>>>>> 18:32:41.570064 (+ 0.000513) sendmsg(32,
>>>>>>>> {msg_name={sa_family=AF_UNIX,
sun_path="/run/systemd/notify"},
>>>>>>>> msg_namelen=21,
msg_iov=[{iov_base="READY=1\nSTATUS=slapd
>>>>>>>> started: Re"..., iov_len=69}], msg_iovlen=1,
msg_controllen=0,
>>>>>>>> msg_flags=0}, MSG_NOSIGNAL) = 69
>>>>>>>> 18:32:41.570845 (+ 0.000789) close(32) = 0
>>>>>>>> 18:32:41.576358 (+ 0.005575) futex(0xb30ed2e8,
FUTEX_WAIT,
>>>>>>>> 16016, NULL) = ?
>>>>>>>> 18:33:01.730774 (+ 20.154428) +++ killed by SIGSEGV
+++
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>
>>>
>>>
>>
>
>