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
<mailto:tbordaz@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 <mailto:mreynolds@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 <mailto:jonathan@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/prprf.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/prprf.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 <mailto:mreynolds@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
>> <
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 <mailto:tbordaz@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/389ds/FAQ/faq.html#debugging-memory-growthinv...
>>>
<
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-memory-growthinv...>).
>>>
>>> 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
>>>> <mailto:tbordaz@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
>>>>> <
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/
>>>>>
<
http://www.gnu.org/software/gdb/bugs/>>.
>>>>> Find the GDB manual and other
>>>>> documentation resources online at:
>>>>>
<
http://www.gnu.org/software/gdb/documentation/
>>>>>
<
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
>>>>> <mailto:rcritten@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#debugging-crashes
>>>>>
<
http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-cras...
>>>>>
>>>>> 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
>>> <mailto:freeipa-users@lists.fedorahosted.org>
>>> To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
>>> <mailto:freeipa-users-leave@lists.fedorahosted.org>
>>
>>
>>
>
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorah...