Sorry, missed your build instructions, only saw them just now. I've just
kicked off that build and I'll check it tomorrow once I'm back in.
One note, it appears it's ./autogen.sh not ./autogen.pl ...
On Thu, May 17, 2018 at 6:16 PM, Jonathan Vaughn <jonathan(a)creatuity.com>
wrote:
Welp, I'm still getting the -fPIC error ... so I may need to
figure out
how to do it with COPR or something.
On Thu, May 17, 2018 at 4:16 PM, Jonathan Vaughn <jonathan(a)creatuity.com>
wrote:
> I've never used COPR. I've dabbled with RPMs in the past but that was...
> CentOS 6 I think, and I wasn't making source code changes so much as just
> copying and pasting SRPMs from another RPM platform to build for CentOS,
> using the regular rpmbuild stuff.
>
> I did actually try just copying the configure line (manually expanding
> the various vars) from the SRPM and just doing an old fashioned make, but
> the first try bailed shy of an hour at linking with some error about not
> having -fPIC specified, so I restarted it with -fPIC to see if it would at
> least build. So if I should still try the code changes, if that build
> finishes I can try it (I was planning to just copy the respective binaries
> on top of the installed ones), but if it turned out the suggested code
> changes were pointless then there's no point waiting for it to finish
> building.
>
> On Thu, May 17, 2018 at 4:11 PM, Rob Crittenden <rcritten(a)redhat.com>
> wrote:
>
>> Jonathan Vaughn via FreeIPA-users wrote:
>> > 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)...
>>
>> If you are handy with rpms you could build it in copr.
>>
>> rob
>>
>> >
>> >
>> > 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.creatuit
>> y.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/replicati
>> on/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/replicat
>> ion/repl5_plugins.c:1124
>> >>>> #7 0xb34be7ec in
multimaster_be_betxnpostop_add
>> >>>> (pb=0x2cb54a0) at
>> >>>> ldap/servers/plugins/replicat
>> ion/repl5_plugins.c:855
>> >>>> #8 0xb34be880 in multimaster_mmr_postop
>> >>>> (pb=<optimized out>, flags=560) at
>> >>>> ldap/servers/plugins/replicat
>> ion/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-growthinvalid-access-with-valgrind
>> >>>> <
http://www.port389.org/docs/
>> 389ds/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
>> >>>>> <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-sl
>> apd-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.fedoraprojec
>> t.org/docs/389ds/FAQ/faq.html#debugging-crashes
>> >>>>>>
<
http://directory.fedoraproje
>>
ct.org/docs/389ds/FAQ/faq.html#debugging-crashes>
>> >>>>>>
>> >>>>>> rob
>> >>>>>>
>> >>>>>>
>> >>>>>> 18:32:41.543717 (+
>> >>>>>> 0.000801)
openat(AT_FDCWD,
>> >>>>>>
"/var/run/dirsrv/slapd-COMPAN
>> Y-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.548030
>> 641
>> >>>>>> "..., 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.551287
>> 555
>> >>>>>> "..., 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.558678
>> 099
>> >>>>>> "..., 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.561718
>> 659
>> >>>>>> "..., 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\n
>> STATUS=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.fedo
>>
rahosted.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.or
>> g/archives/list/freeipa-users(a)lists.fedorahosted.org/message
>> /NNFFJQTAJ2MG52U23V6QYOOAFL722JJL/
>> >
>>
>>
>