Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com
--On Wednesday, October 28, 2015 5:23 PM +0000 maurizio.lattuada(a)gmail.com
wrote:
> --001a1130d27c49538c05232c9dd4
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> I cloned the git repository "git://git.openldap.org/openldap.git", then I
> compiled this version "2.X" as specified in the 1st message.
> Please consider that, after recompiling this version, I rebooted the
> server where slapd is running.
>
> As far as I can see, it seems the memory consumption is the same as
> 2.4.42: it starts to increase up to 60%.
> In fact, with gdb, I got now an assertion failed due to:
You can check out just RE24 specifically via:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 7 months
Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com
--001a1130d27c49538c05232c9dd4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I cloned the git repository "git://git.openldap.org/openldap.git", then I
compiled this version "2.X" as specified in the 1st message.
Please consider that, after recompiling this version, I rebooted the server
where slapd is running.
As far as I can see, it seems the memory consumption is the same as 2.4.42:
it starts to increase up to 60%.
In fact, with gdb, I got now an assertion failed due to:
----
5630f547 connection_get(22): got connid=3D1001
5630f547 connection_read(22): checking for input on id=3D1001
ber_get_next
ber_get_next: tag 0x30 len 188 contents:
5630f547 op tag 0x66, time 1446049095
ber_get_next
5630f547 conn=3D1001 op=3D46535 do_modify
ber_scanf fmt ({m) ber:
ber_scanf fmt ({e{m[W]}}) ber:
5630f547 =3D> get_ctrls
ber_scanf fmt ({m) ber:
5630f547 =3D> get_ctrls: oid=3D"2.16.840.1.113730.3.4.2" (noncritical)
5630f547 <=3D get_ctrls: n=3D1 rc=3D0 err=3D""
5630f547 >>> dnPrettyNormal:
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>
5630f547 <<< dnPrettyNormal:
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>,
<cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch>
5630f547 >>> dnPretty: <cn=3DSimon
Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>
5630f547 <<< dnPretty: <cn=3DSimon
Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>
5630f547 >>> dnNormalize: <cn=3DSimon
Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>
5630f547 <<< dnNormalize: <cn=3Dsimon
cottet.7601000061447,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch>
5630f547
bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate=
s,c=3Dch")
5630f547 bdb_entry_get: rc=3D0
5630f547 syncprov_matchops: sid ffffffff fscope 1 rc 6
5630f547 =3D=3D> unique_modify
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>
5630f547
bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate=
s,c=3Dch")
5630f547 bdb_entry_get: rc=3D0
5630f547 unique_modify: administrative bypass, skipping
5630f547 bdb_modify: txn1 id: 80005c1f
5630f547
bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivate=
s,c=3Dch")
5630f547 bdb_modify: txn2 id: 80005c20
5630f547 bdb_modify_internal: 0x00000288:
cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch
5630f547 oc_check_required entry
(cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch), ob=
jectClass
"VivatesHCRelationship"
5630f547 oc_check_allowed type "relationshipType"
5630f547 oc_check_allowed type "owner"
5630f547 oc_check_allowed type "objectClass"
5630f547 oc_check_allowed type "cn"
5630f547 oc_check_allowed type "member"
5630f547 oc_check_allowed type "structuralObjectClass"
5630f547 oc_check_allowed type "entryUUID"
5630f547 oc_check_allowed type "creatorsName"
5630f547 oc_check_allowed type "createTimestamp"
5630f547 oc_check_allowed type "entryCSN"
5630f547 oc_check_allowed type "modifiersName"
5630f547 oc_check_allowed type "modifyTimestamp"
5630f547 =3D> key_change(DELETE,288)
5630f547 <=3D key_change 0
5630f547 =3D> key_change(ADD,288)
5630f547 <=3D key_change 0
5630f547 =3D> entry_encode(0x00000288):
cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch
5630f547 ch_malloc of 837196 bytes failed
slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x9baffb70 (LWP 3069)]
0x00130424 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install
libtool-ltdl-2.2.6-15.5.el6.i686
(gdb) bt
#0 0x00130424 in __kernel_vsyscall ()
#1 0x003ac871 in raise (sig=3D6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x003ae14a in abort () at abort.c:92
#3 0x003a5b8b in __assert_fail_base (fmt=3D0x4dad58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=3D0x81c79c9 "0", file=3D0x81ac34=
7
"ch_malloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at assert.c:96
#4 0x003a5c46 in __assert_fail (assertion=3D0x81c79c9 "0", file=3D0x81ac34=
7
"ch_malloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at assert.c:105
#5 0x0809768a in ch_malloc (size=3D837196) at ch_malloc.c:57
#6 0x080857d1 in entry_encode (e=3D0x9bafdb9c, bv=3D0x9bafda04) at entry.c=
:710
#7 0x0814a4a5 in bdb_id2entry_put (be=3D<value optimized out>, tid=3D<valu=
e
optimized out>, e=3D<value optimized out>, flag=3D0) at id2entry.c:54
#8 0x080fa6f4 in bdb_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c=
:679
#9 0x080e884d in overlay_op_walk (op=3D0xa22b3bd8, rs=3D0x9baff0cc,
which=3Dop_modify, oi=3D0x8353670, on=3D0x0) at backover.c:696
#10 0x080e94e9 in over_op_func (op=3D0xa22b3bd8, rs=3D0x9baff0cc,
which=3Dop_modify) at backover.c:749
#11 0x080944b1 in fe_op_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at
modify.c:303
#12 0x08094f27 in do_modify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:=
177
#13 0x0807b043 in connection_operation (ctx=3D0x9baff1e8, arg_v=3D0xa22b3bd=
8)
at connection.c:1137
#14 0x0807bb57 in connection_read_thread (ctx=3D0x9baff1e8, argv=3D0x16) at
connection.c:1283
#15 0x0013d309 in ldap_int_thread_pool_wrapper (xpool=3D0x8299a40) at
tpool.c:956
#16 0x0036db39 in start_thread (arg=3D0x9baffb70) at pthread_create.c:301
#17 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
----
So, a malloc failed returning NULL.
This happens also with the 2.4.42.
Now I relaunch again the loading procedure and see what's happening.
2015-10-28 16:41 GMT+01:00 Michael Str=C3=B6der <michael(a)stroeder.com>:
> Any chance for you to test RE24 branch with the code to be released as
> 2.4.43?
>
> There were some fixes for crashing syncrepl added therein.
>
> Ciao, Michael.
>
--=20
Maurizio Lattuada
--001a1130d27c49538c05232c9dd4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I cloned the git repository "<span style=3D"color:rgb=
(0,0,0);font-family:sans-serif;font-size:13px">git://<a href=3D"http://git.=
openldap.org/openldap.git">git.openldap.org/openldap.git</a>",=C2=A0</=
span><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px"=
>then I compiled this version "2.X" as specified in the 1st messa=
ge.</span><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-=
size:13px">Please consider that, after recompiling this version, I rebooted=
the server where slapd is running.</span><font color=3D"#000000" face=3D"s=
ans-serif"><br></font></div><div><font color=3D"#000000" face=3D"sans-serif=
"><br></font><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;fo=
nt-size:13px">As far as I can see, it seems the memory consumption is the s=
ame as 2.4.42: it starts to increase up to 60%.</span></div><div><span styl=
e=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px">In fact, with =
gdb, I got now an assertion failed due to:</span><br></div><div><span style=
=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"color:rgb(0,0,0);font-family:sans-serif;font-size:13p=
x">----</span></div><div><div style=3D""><font color=3D"#000000" face=3D"sa=
ns-serif">5630f547 connection_get(22): got connid=3D1001</font></div><div s=
tyle=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 connection_r=
ead(22): checking for input on id=3D1001</font></div><div style=3D""><font =
color=3D"#000000" face=3D"sans-serif">ber_get_next</font></div><div style=
=3D""><font color=3D"#000000" face=3D"sans-serif">ber_get_next: tag 0x30 le=
n 188 contents:</font></div><div style=3D""><font color=3D"#000000" face=3D=
"sans-serif">5630f547 op tag 0x66, time 1446049095</font></div><div style=
=3D""><font color=3D"#000000" face=3D"sans-serif">ber_get_next</font></div>=
<div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 conn=
=3D1001 op=3D46535 do_modify</font></div><div style=3D""><font color=3D"#00=
0000" face=3D"sans-serif">ber_scanf fmt ({m) ber:</font></div><div style=3D=
""><font color=3D"#000000" face=3D"sans-serif">ber_scanf fmt ({e{m[W]}}) be=
r:</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">=
5630f547 =3D> get_ctrls</font></div><div style=3D""><font color=3D"#0000=
00" face=3D"sans-serif">ber_scanf fmt ({m) ber:</font></div><div style=3D""=
><font color=3D"#000000" face=3D"sans-serif">5630f547 =3D> get_ctrls: oi=
d=3D"2.16.840.1.113730.3.4.2" (noncritical)</font></div><div styl=
e=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <=3D get_ctr=
ls: n=3D1 rc=3D0 err=3D""</font></div><div style=3D""><font color=
=3D"#000000" face=3D"sans-serif">5630f547 >>> dnPrettyNormal: <=
cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch></=
font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630=
f547 <<< dnPrettyNormal: <cn=3D1000000000000_O2HP,ou=3DRelation=
ship,dc=3DHPD,o=3Dvivates,c=3Dch>, <cn=3D1000000000000_o2hp,ou=3Drela=
tionship,dc=3Dhpd,o=3Dvivates,c=3Dch></font></div><div style=3D""><font =
color=3D"#000000" face=3D"sans-serif">5630f547 >>> dnPretty: <c=
n=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=
=3Dch></font></div><div style=3D""><font color=3D"#000000" face=3D"sans-=
serif">5630f547 <<< dnPretty: <cn=3DSimon Cottet.7601000061447,=
ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch></font></div><div style=
=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 >>> dnN=
ormalize: <cn=3DSimon Cottet.7601000061447,ou=3DHCProfessional,dc=3DHPD,=
o=3Dvivates,c=3Dch></font></div><div style=3D""><font color=3D"#000000" =
face=3D"sans-serif">5630f547 <<< dnNormalize: <cn=3Dsimon cotte=
t.7601000061447,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch></font><=
/div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 b=
db_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvi=
vates,c=3Dch")</font></div><div style=3D""><font color=3D"#000000" fac=
e=3D"sans-serif">5630f547 bdb_entry_get: rc=3D0</font></div><div style=3D""=
><font color=3D"#000000" face=3D"sans-serif">5630f547 syncprov_matchops: si=
d ffffffff fscope 1 rc 6</font></div><div style=3D""><font color=3D"#000000=
" face=3D"sans-serif">5630f547 =3D=3D> unique_modify <cn=3D1000000000=
000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch></font></div><div=
style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 bdb_dn2ent=
ry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=
=3Dch")</font></div><div style=3D""><font color=3D"#000000" face=3D"sa=
ns-serif">5630f547 bdb_entry_get: rc=3D0</font></div><div style=3D""><font =
color=3D"#000000" face=3D"sans-serif">5630f547 unique_modify: administrativ=
e bypass, skipping</font></div><div style=3D""><font color=3D"#000000" face=
=3D"sans-serif">5630f547 bdb_modify: txn1 id: 80005c1f</font></div><div sty=
le=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 bdb_dn2entry(&=
quot;cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch&=
quot;)</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-ser=
if">5630f547 bdb_modify: txn2 id: 80005c20</font></div><div style=3D""><fon=
t color=3D"#000000" face=3D"sans-serif">5630f547 bdb_modify_internal: 0x000=
00288: cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dc=
h</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5=
630f547 oc_check_required entry (cn=3D1000000000000_O2HP,ou=3DRelationship,=
dc=3DHPD,o=3Dvivates,c=3Dch), objectClass "VivatesHCRelationship"=
</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">56=
30f547 oc_check_allowed type "relationshipType"</font></div><div =
style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_al=
lowed type "owner"</font></div><div style=3D""><font color=3D"#00=
0000" face=3D"sans-serif">5630f547 oc_check_allowed type "objectClass&=
quot;</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-seri=
f">5630f547 oc_check_allowed type "cn"</font></div><div style=3D"=
"><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed typ=
e "member"</font></div><div style=3D""><font color=3D"#000000" fa=
ce=3D"sans-serif">5630f547 oc_check_allowed type "structuralObjectClas=
s"</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-se=
rif">5630f547 oc_check_allowed type "entryUUID"</font></div><div =
style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_al=
lowed type "creatorsName"</font></div><div style=3D""><font color=
=3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed type "creat=
eTimestamp"</font></div><div style=3D""><font color=3D"#000000" face=
=3D"sans-serif">5630f547 oc_check_allowed type "entryCSN"</font><=
/div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 o=
c_check_allowed type "modifiersName"</font></div><div style=3D"">=
<font color=3D"#000000" face=3D"sans-serif">5630f547 oc_check_allowed type =
"modifyTimestamp"</font></div><div style=3D""><font color=3D"#000=
000" face=3D"sans-serif">5630f547 =3D> key_change(DELETE,288)</font></di=
v><div style=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <=
=3D key_change 0</font></div><div style=3D""><font color=3D"#000000" face=
=3D"sans-serif">5630f547 =3D> key_change(ADD,288)</font></div><div style=
=3D""><font color=3D"#000000" face=3D"sans-serif">5630f547 <=3D key_chan=
ge 0</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif=
">5630f547 =3D> entry_encode(0x00000288): cn=3D1000000000000_O2HP,ou=3DR=
elationship,dc=3DHPD,o=3Dvivates,c=3Dch</font></div><div style=3D""><font c=
olor=3D"#000000" face=3D"sans-serif">5630f547 ch_malloc of 837196 bytes fai=
led</font></div><div style=3D""><font color=3D"#000000" face=3D"sans-serif"=
>slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed.</font></div><d=
iv style=3D""><font color=3D"#000000" face=3D"sans-serif"><br></font></div>=
<div style=3D""><font color=3D"#000000" face=3D"sans-serif">Program receive=
d signal SIGABRT, Aborted.</font></div><div style=3D""><font color=3D"#0000=
00" face=3D"sans-serif">[Switching to Thread 0x9baffb70 (LWP 3069)]</font><=
/div><div style=3D""><font color=3D"#000000" face=3D"sans-serif">0x00130424=
in __kernel_vsyscall ()</font></div><div style=3D""><font color=3D"#000000=
" face=3D"sans-serif">Missing separate debuginfos, use: debuginfo-install l=
ibtool-ltdl-2.2.6-15.5.el6.i686</font></div></div><div style=3D""><font col=
or=3D"#000000" face=3D"sans-serif"><br></font></div><div style=3D""><font c=
olor=3D"#000000" face=3D"sans-serif"><div>(gdb) bt</div><div>#0 =C2=A00x001=
30424 in __kernel_vsyscall ()</div><div>#1 =C2=A00x003ac871 in raise (sig=
=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64</div><div>#2 =C2=A00x00=
3ae14a in abort () at abort.c:92</div><div>#3 =C2=A00x003a5b8b in __assert_=
fail_base (fmt=3D0x4dad58 "%s%s%s:%u: %s%sAssertion `%s' failed.\n=
%n", assertion=3D0x81c79c9 "0", file=3D0x81ac347 "ch_ma=
lloc.c", line=3D57, function=3D0x81ac3df "ch_malloc") at ass=
ert.c:96</div><div>#4 =C2=A00x003a5c46 in __assert_fail (assertion=3D0x81c7=
9c9 "0", file=3D0x81ac347 "ch_malloc.c", line=3D57, fun=
ction=3D0x81ac3df "ch_malloc") at assert.c:105</div><div>#5 =C2=
=A00x0809768a in ch_malloc (size=3D837196) at ch_malloc.c:57</div><div>#6 =
=C2=A00x080857d1 in entry_encode (e=3D0x9bafdb9c, bv=3D0x9bafda04) at entry=
.c:710</div><div>#7 =C2=A00x0814a4a5 in bdb_id2entry_put (be=3D<value op=
timized out>, tid=3D<value optimized out>, e=3D<value optimized=
out>, flag=3D0) at id2entry.c:54</div><div>#8 =C2=A00x080fa6f4 in bdb_m=
odify (op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:679</div><div>#9 =C2=
=A00x080e884d in overlay_op_walk (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which=
=3Dop_modify, oi=3D0x8353670, on=3D0x0) at backover.c:696</div><div>#10 0x0=
80e94e9 in over_op_func (op=3D0xa22b3bd8, rs=3D0x9baff0cc, which=3Dop_modif=
y) at backover.c:749</div><div>#11 0x080944b1 in fe_op_modify (op=3D0xa22b3=
bd8, rs=3D0x9baff0cc) at modify.c:303</div><div>#12 0x08094f27 in do_modify=
(op=3D0xa22b3bd8, rs=3D0x9baff0cc) at modify.c:177</div><div>#13 0x0807b04=
3 in connection_operation (ctx=3D0x9baff1e8, arg_v=3D0xa22b3bd8) at connect=
ion.c:1137</div><div>#14 0x0807bb57 in connection_read_thread (ctx=3D0x9baf=
f1e8, argv=3D0x16) at connection.c:1283</div><div>#15 0x0013d309 in ldap_in=
t_thread_pool_wrapper (xpool=3D0x8299a40) at tpool.c:956</div><div>#16 0x00=
36db39 in start_thread (arg=3D0x9baffb70) at pthread_create.c:301</div><div=
>#17 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133<=
/div><div><br></div><div>----</div><div><br></div><div><br></div><div>So, a=
malloc failed returning NULL.</div><div>This happens also with the 2.4.42.=
</div><div><br></div><div><br></div><div>Now I relaunch again the loading p=
rocedure and see what's happening.</div></font></div></div></div><div c=
lass=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-10-28 16:41 GMT+01=
:00 Michael Str=C3=B6der <span dir=3D"ltr"><<a href=3D"mailto:michael@st=
roeder.com" target=3D"_blank">michael(a)stroeder.com</a>></span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">Any chance for you to test RE24 branch with the c=
ode to be released as 2.4.43?<br>
<br>
There were some fixes for crashing syncrepl added therein.<br>
<br>
Ciao, Michael.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr">=C2=A0Maurizio Lattuada<br></div></di=
v>
</div>
--001a1130d27c49538c05232c9dd4--
7 years, 7 months
(ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com
Full_Name: Maurizio Lattuada
Version: 2.4.42
OS: CentOS 6.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.51.144.162)
Hello @all.
some details:
* OpenLDAP 2.4.42
** compiled as "./configure --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=i686-redhat-linux-gnu --program-prefix=
--prefix=/usr --exec-prefix=/usr --libexecdir=/usr/lib --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include --libdir=/usr/lib --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-threads=posix --enable-dynamic --enable-syslog --enable-slapd
--enable-cleartext --enable-crypt --enable-spasswd --enable-modules
--enable-rewrite --enable-rlookups --enable-bdb=yes --enable-hdb=yes
--enable-ldap=yes --enable-monitor=yes --enable-relay=yes --enable-auditlog=mod
--enable-constraint=mod --enable-dyngroup=mod --enable-dynlist=mod
--enable-unique=mod"
* CentOS 6.6 (32 bit, i686)
Here the slapd.conf (converted to slapd.d folder via slapdtest)
---- slapd.conf (begin) ----
include /etc/openldap/schema/rorba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema%0nclulude
/etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/dicom_supplement_67.schema
include /etc/openldap/schema/tiani-spirit.schema
include /etc/openldap/schema/tiani-hl7.schema
include /etc/openldap/schema/tiani-hl7_pix.schema
include /etc/openldap/schema/tiani-xds.schema
include /etc/openldap/schema/tiani-authorization.schema
include /etc/openldap/schema/spirit-configuration.schema
include /etc/openldap/schema/spirit-svs.schema
include /etc/openldap/schema/etoile.schema
include /etc/openldap/schema/hpd.schema
include /etc/openldap/schema/vivates.schema
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib/openldap
moduleload unique.la
moduleload syncprov.la
# First database definistion
database bdb
suffix 2o2o=spirit,c=at"
checkpoint 1024 15
rootdn "cn=root,o=spirit,c=at"
rootpw xxx
directory /var/lib/ldap
# Second database definistion
database bdb
suffix "o=vivates,c=ch"
checkpoint 1024 15
rootdn "cn=root,o=vivates,c=ch"
rootpw yyy
direorory /var/lib/ldap-hpd
overlay unique
unique_attributes hcIdentifier
overlay syncprov
syncprov-checkpoint 1000 10
syncprov-sessionlog 1000
syncprov-reloadhint TRUE
syncprov-nopresent FALSE
# enable monitoring
database monitor
# ppolicy added
access to * by self write
by users read
by users auth
by anonymous read
---- slapd.conf (end) ----
I'm loading in a schema and simultaneously I've a client synchronizing with this
schema using syncprov module (RFC4533).
This schema has about 20k entries to be saved in the 2nd database (see above for
the db definition).
I notice 2 strange events:
1) the %MEM consumption (as shown by top) increases of 1% every 10s (memory
leak?)
2) I always have an assertion failed more or less at the same entry I've to
load (about 5k out of 20k), and the memory consumption of slapd is about 66%
Both happen
* also with OpenLDAP 2.4.41 (compiled as said above)
* only when the client application (using syncprov) is running simultaneously
with slapd. If I stop that client application, I load all the 20k entries, then
I start it: slapd works fine, no assertions are failed and the synchronization
with syncprov (used by our client application) work flawless.
Here the trace obtained with gdb:
---- GDB (begin) -----
[root@ibb0301 .libs]# pwd
/root/openldap/openldap-2.4.42/servers/slapd/.libs
[root@ibb0301 .libs]# file ./slapd
./slapd: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
[root@ibb0301 .libs]# ./slapd -VVV
@(#) $OpenLDAP: slapd 2.4.42 (Oct 28 2015 15:36:46) $
root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd
Included static overlays:
syncprov
Included static backends:
config
ldif
monitor
bdb
hdb
ldap
mdb
relay
[root@ibb0301 .libs]# gdb ./slapd
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL versn n 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 "i686-redhat-lin-gnunu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/root/openldap/openldap-2.4.42/servers/slapd/.libs/slapd...done.
(gdb) run -d 1 -h ldap://
Starting program: /root/openldap/openap-2-2.4.42/servers/slapd/.libs/slapd -d 1
-h ldap://
[Thread debugging using libthread_db enabled]
ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /etc/openldap/ldap.conf
ldap_init: using /etc/openldap/ldap.conf
ldap_url_parse_ext(ldap://localhost/)
ldap_init: HOME env is /root
ldap_init: trying /root/ldaprc
ldap_init: trying /root/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
5630e030 @(#) $OpenLDAP: slapd 2.4.42 ,tct 28 2015 15:36:46) $
root@ibb0301:/root/openldap/openldap-2.4.42/servers/slapd
ldap_pvt_gethostbyname_a: host=ibb0301, r=0
5630e030 daemon_init: listen on ldap://
5630e030 daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://)
50e03030 daemon: listener initialized ldap://
5630e030 daemon_init: 2 listeners opened
5630e030 slapd init: initiated server.
5630e030 slap_sasl_init: initialized!
5630e030 bdb_back_initialize: initialize BDB backend
5630e030 bdb_back_initialize: Berkeley DB 4.7.25: (Septemr r 22, 2015)
5630e030 hdb_back_initialize: initialize HDB backend
5630e030 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015)
5630e030 mdb_back_initialize: initialize MDB backend
5630e030 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015)
CUT CUT CUT
5630e9d2 connection_get(22): got connid=1001
5630e9d2 connection_read(22): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 127 contents:
5630e9d2 op tag 0x63, time 1446046162
ber_get_next
5630e9d2 conn=1001 op=45593 do_search
ber_scanf fmt ({miiiib) ber:
5630e9d2 >>> dnPrettyNormal:
<cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>
5630e9d2 <<< dnPrettyNormal:
<cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>,
<cn=1000000000000_o2hp%ouou=relationship,dc=hpd,o=vivates,c=ch>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
5630e9d2 => get_ctrls
ber_scanf fmt ({m) ber:
5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical)
5630e9d2 <= get_ctrls:%n=1 rc=0 err=""
5630e9d2 => bdb_search
5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch")
5630e9d2 => send_search_entry: conn 1001
dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"
ber_flush2: 412214 bytes to sd 22
5630e9d2 <= send_search_entry: conn 1001 exit.
5630e9d2 send_ldap_result: conn=1001 op=45593 p=3
5630e9d2 send_ldap_response: msgid=45594 tag=101 err=0
ber_flush2: 16 bytes to sd 22
5630e9d2 connection_get(22): got connid=1001
5630e9d2 connection_read(22): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 187 contents:
5630e9d2 op tag 0x66, time 1446046162
ber_get_next
5630e9d2 conn=1001 op=45594 do_modify
ber_scanf fmt ({m) ber:
ber_scanf fmt ({e{m[W]}}) ber:
5630e9d2 => get_ctrlsŸr_r_scanf fmt ({m) ber:
5630e9d2 => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical)
5630e9d2 <= get_ctrls: n=1 rc=0 err=""
5630e9d2 >>> dnPrettyNormal:
<cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>
5630e9d2 <<< dnPrettyNormal:
<cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>,
<cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch>
5630e9d2 >>> dnPretty: <cn=Sylvain
Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch>
5630e9d2 <<< dnPretty: <cn=Sylvain
Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch>
5630e9d2 >>> dnNormalize: <cn=Sylvain
Roy.7601000348999,ou=HCProfessional,dc=HPD,o=vivates,c=ch>
5630e9d2 <<< dnNormalize: <cn=sylvain
roy.7601000348999,ou=hcprofessional,dc=hpd,o=vivat%2,c=ch>
5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch")
5630e9d2 bdb_entry_get: rc=0
5630e9d2 syncprov_matchops: sid ffffffff fscope 1 rc 6
5630e9d2 ==> unique_modify
<cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch>
5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch")
5630e9d2 bdb_entry_get: rc=0
5630e9d2 unique_modify: administrative bypass, skipping
5630e9d2 bdb_modify: txn1 id: 80005adb
5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch")
5630e9d2 bdb_modify: txn2 id: 80005adc
5630e9d2 bdb_modify_internal: 0x00000288:
cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch
5630e9d2 oc_check_required entry
(cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch), objectClass
"VivatesHCRelationship"
5630e9d2 oc_check_allowed type "relationshipType"
5630e9d2 oc_check_allowed type "owner"
5630e9d2 oc_check_allowed type "objectClass"
5630e9d2 oc_check_allowed type "cn"
5630e9d2 oc_check_allowed type "member"
5630e9d2 oc_check_allowed type "structuralObjectClass"
5630e9d2 oc_check_allowed type "entryUUID"
5630e9d2 oc_check_allowed type "creatorsName"
5630e9d2 oc_check_allowed type "createTimestamp"
5630e9d2 oc_check_allowed type "entryCSN"
5630e9d2 oc_check_allowed type "modifiersName"
5630e9d2 oc_check_allowed type "modifyTimestamp"
5630e9d2 => key_change(DELETE,288)
5630e9d2 <= key_change 0
5630e9d2 => key_change(ADD,288)
5630e9d2 <= key_change 0
5630e9d2 => entry_encode(0x00000288):
cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch
5630e9d2 <= entry_encode(0x00000288):
cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch
5630e9d2 bdb_modify: updated id=00000288
dn="cn=1000000000000_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"
5630e9d2 send_ldap_result: conn=1001 op=45594 p=3
5630e9d2 bdb_dn2entry("cn=1000000000000_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch")
5630e9d2 bdb_entry_get: rc=0
slapd: attr.c:238: attr_dup2: Assertion `j < i' failed.
Program received signaSISIGABRT, Aborted.
[Switching to Thread 0xa0afab70 (LWP 2387)]
0x00130424 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install
libtool-ltdl-2.2.6-15.5.el6.i686
(gdb) bt
#0 0x00130424 in __kernel_vsyscall ()
#1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0x003ae14a in abort () at abort.c:92
#3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion
`%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c",
line=238, function=0x8199ee3 "attr_dup2") at assert.c:96
#4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa
"attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105
#5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238
#6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282
#7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940
#8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949
#9 0x0817a08d in syncprov_matops s (op=0x83820c0, opc=0xa05f936c, saveit=0) at
syncprov.c:1220
#10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at
syncprov.c:1969
#11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at
result.c:508
#12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at
result.c:583
#13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at
result.c:861
#14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802
#15 0x080e3f73 in overlay_op_walk (%3=0x83820c0, rs=0xa0afa0dc, which=op_modify,
oi=0x833c680, on=0x0) at backover.c:677
#16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at
backover.c:730
#17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.cA3A303
#18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177
#19 0x080782bc in connection_operation (ctx=0xa0afa1ec, arg_v=0x83820c0) at
connection.c:1155
#20 0x08078b57 in connection_read_thread (ctx=0xa0afa1ec, argv=0x16) at
connection.c:1291
#21 0x0013c5e4 in ldap_int_thread_pool_wrapper (xpool=0x8287b80) at tpool.c:696
#22 0x0036db39 in start_thread (arg=0xa0afab70) at pthread_create.c:301
#23 0x00464c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
(gdb) bt full
#0 0x00130424 in __kernel_vsyscall ()
No symbol table info available.
#1 0x003ac871 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = <value optimized out>
resultvar =3<value optimized out>
pid = 5324788
selftid = 2387
#2 0x003ae14a in abort () at abort.c:92
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask
= {__val = {5324788, 64, 1, 4137890, 2695856544, 0, 104, 57, 2718957584,
5324788, 57, 56, 2695856716, 4109330, 1563184960, 57, 2695856756, 1563184960, 0,
4222451712, 1563184960,
1563184960, 1563184960, 1563184960, 1563185016, 1563185060,
1563184960, 1563185060, 0, 0, 0, 0}}, sa_flags = 0, sa_restorer = 0x4d84d8
<_libc_intl_domainname>}
sigs = {__val = {32, 0 <repeats 31 times>}}
#3 0x003a5b8b in __assert_fail_base (fmt=0x4dad58 "%s%s%s:%u: %s%sAssertion
`%s' failed.\n%n", assertion=0x8199ecb "j < i", file=0x8199eaa "attr.c",
line=238, function=0x8199ee3 "attr_dup2") at assert.c:96
str = 0x5d2c4f40 ""
total = 4096
#4 0x003a5c46 in __assert_fail (assertion=0x8199ecb "j < i", file=0x8199eaa
"attr.c", line=238, function=0x8199ee3 "attr_dup2") at assert.c:105
No locals.
#5 0x08081b5f in attr_dup2 (tmp=0xbd3a26bc, a=0x5c85e354) at attr.c:238
i = <value optimized out>
j = 1171
__PRETTY_FUNCTION__ = "attr_dup2"
#6 0x08081ecd in attrs_dup (a=0x5c85e354) at attr.c:282
i = <value optimized out>
tmp = 0xbd3a26bc
anew = 0x365765ec
#7 0x08082704 in entry_dup2 (dest=0xb99e6a34, source=0x8372ea4) at entry.c:940
__PRETTY_FUNCTION__ = "entry_dup2"
#8 0x08082fea in entry_dup (e=0x8372ea4) at entry.c:949
No locs.s.
#9 0x0817a08d in syncprov_matchops (op=0x83820c0, opc=0xa05f936c, saveit=0) at
syncprov.c:1220
on = 0x834c270
si = 0x834c378
fc = {fdn = 0x83820dc, fss = 0x36f3b7, fbase = -1599109284, fscope =
2387}
pss = <value optimized out>
e = 0x8372ea4
a = <value optimized out>
rc = 0
gonext = <value optimized out>
newdn = {bv_len = 2721065128, bv_val = 0xa0af8778
"8\210\257\240\066\253\027\b\330\303\064\b\024\210\257\240\034\210\257\240",
<incomplete sequence \334>}
freefdn = 0
b0 = 0xa0af8cb0
db = {bd_info = 0x3006c4, bd_self = 0x3006c4, be_ctrls =
"\350.0\242\210\205\257\240\270\f\000\000P\322.\bE\000\000\000\000\000\000\000\300\316.\b\270\254?\243
", be_flags = 2, be_restrictops = 0, be_requires = 137286224, be_ssf_set =
{sss_ssf = 2739079224,
sss_transport = 2739079264, sss_tls = 2738856128, sss_sasl =
137288792, sss_update_ssf = 137284672, sss_update_transport = 2738858688,
sss_update_tls = 137122904, sss_update_sasl = 2721067280, sss_simple_bind = 0},
be_suffix = 0xa3430860, be_nsuffix = 0x0,
be_schemadn = {bv_len = 2721066704, bv_val = 0x0}, be_schemandn =
{bv_len = 1785995, bv_val = 0x3006c4 "\270=\027"}, be_rootdn = {bv_len =
137122904, bv_val = 0xa0af89f8
"8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"}, be_rootndn = {
---Type <return> to continue, or q <return> to quit---
bv_len = 2695857784, bv_val = 0x1af848
"=P\207\377\377\211\307\017\5%5\315\376\377\377\203}\024\003\017\204",
<incomplete sequence \341>}, be_rootpw = {bv_len = 137122904, bv_val =
0xa0af89f8 "8\212\257\240\343I\023\b@\211\037\bx6\204#\340\226?\242"},
be_max_deref_depth = 2695858652, be_def_limit = {lms_t_soft = 6,
lms_t_hard = 0, lms_sofoft = -1573902056, lms_s_hard = -1573901176,
lms_s_unchecked = -1573899696, lms_s_pr = -1555836884, lms_s_pr_hide =
-1555836892, lms_s_pr_total = 2472655},
be_limits = 0x3006c4, be_acl = 0x0, be_dfltaccess = -1573900016,
be_extra_anlist = 0xa0af8778, be_update_ndn = {bv_len = 2485336, bv_val = 0x0},
be_update_refs = 0xa0af88a4, be_pending_csn_list = 0xa0af8820, be_pcl_mutex =
{__data = {__lock = -1768966555,
__count = 137125596, __owner = 137121936, __kind = 24684, __nusers
= 0, {__spins = -1599109576, __list = {__next = 0xa0af8638}}}, __size =
"e\266\217\226\334^,\b\220P,\bl`\000\000\000\000\000\000\070\206\257\240",
__align = -1768966555},
be_syncinfo = 0x3752c2, be_pb = 0xa33e2250, be_cf_ocs = 0x1d,
be_private = 0x0, be_next = {stqe_next = 0x606c}}
#10 0x0817ab36 in syncprov_op_response (op=0x83820c0, rs=0xa0afa0dc) at
syncprov.c:1969
maxcsn = {bv_len = 40, bv_val = 0xa0af87d4
"20151028152922.245192Z#000000#000#000000"}
cbuf = "20151028152922.245192Z#000000#000#000000\000\000\000\000\240SQ\000\030\000\000\000\020\067\204#\364\017\030\000x6\204#"
do_check = <value optimized out>
foundit = 1
csn_changed = 1
have_psearches = 1
opc = 0xa05f936c
on = 0x834c270
si = 0x834c378
sm = <value optimized out>
#11 0x080880a6 in slap_response_play (op=0x83820c0, rs=0xa0afa0dc) at
result.c:508
sc_next = 0xa0af8dac
sc_nextp = 0xa05f9358
rc = 32768
sc = 0xa05f9358
scp = 0xa0af886c
#12 0x08088c94 in send_ldap_response (op=0x83820c0, rs=0xa0afa0dc) at
result.c:583
berbuf = {
buffer = "\000\000\000\000\340\066\066\243T\225A\213\250\066\066\243",
'\000' <repeats 12 times>, " \000\000\000\000\000\000\000\001\000\000\000\300
6\243\340\326.\b\005\000\000\000\177\222M\000\000\000\002\000\000\000\000\000\n\000\000\000\322\351\060V\000\000\000\000\000\000\000\000\020\000\060\242\377\377\377\377\035\003,\000\304\006\060\000x6\204#P\322.\b良\240G3%3,\000P\322.\bx6\204#\340\066\066\243\005\000\000\000\001\000\000\000\322\351\060V\227\235\376\257\000\000\000\000\350^ڻ",
'\000' <repeats 12 times>,
"\002\000\000\000\000\000\000\000ˠ\027\000\215\a.\000d':\275\000\000\000\000\230\211\257\240\4%4\211\257\240\267\363\066\000\227\235\376\257\250\066\066\243P\322.\bd':\275\a",
'\000' <repeats 31 times>"\354, eW6\370\211\257\000e\266\217\226", ialign = 0,
lalign = 0,
falign = 0, dalign = -4.663540245266185e-139, palign = 0x0}
ber = 0xa0af88c0
rc = 0
bytes = <value optimized out>
__PRETTY_FUNCTION__ = "send_ldap_response"
#13 0x08089ad2 in slap_send_ldap_result (op=0x83820c0, rs=0xa0afa0dc) at
result.c:861
tmp = 0x0
otext = 0x0
oref = 0x0
__PRETTY_FUNCTION__ = "slap_send_ldap_result"
#14 0x080f1262 in bdb_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:802
bdb = 0x833fb60
e = <value optimized out>
ei = 0xa23f96e0
manageDSAit = 2
textbuf = "e\266\217\226Ӹ4\242\000\000\000\000\000\000\000\000\024A\255\000\300
8\b\374=\037\b8\214\257\240\034*\255\000\300 8\b\244.7\b\000\000\000\000
\376\063\b", '\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>,
"\026\000\000\000\220\270\064\242\026\000\000\000
\376\063\b\000\000\000\000\000\000\000\000<\213\257\240", '\000' <repeats 20
times>, "@\377\063\b\000\000\000\000\000\000\000\000\300\223_\240\230!8\bf\000\000\000\322\351\060V\017\000\000\000\260\214\257\240;\000\000\0000%0\222_\240;\000\000\000\020\223_---Type
<return> to continue, or q <return> to quit---
\240\000H\224^", '\000' <repeats 71 times>
ltid = 0x0
lt2 = 0x396fd3b8
opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x0}, boi_txn =
0x23843678, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 0
'\000'}
dummy = {e_id = 648, e_name = {bv_len = 59, bv_val = 0xa23f91f0 "cn=1",
'0' <repeats 12 times>, "_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"}, e_nname
=7B7Bbv_len = 59,
bv_val = 0xa23f9230 "cn=1", '0' <repeats 12 times>,
"_o2hp,ou=relationship,dc=hpd,o=vivates,c=ch"}, e_attrs = 0x0, e_ocflags =
65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0xa23f96e0}
lock =7B7Boff = 120744, ndx = 605, gen = 6432, mode = DB_LOCK_WRITE}
num_retries = 0
preread_ctrl = 0x0
postread_ctrl = 0x0
ctrls = {0x0, 0x16, 0x29be4bb8, 0x0, 0x0, 0x0}
num_ctrls = 0
rc = <value optimized out>
#15 0x080e3f73 in overlay_op_walk (op=0x83820c0, rs=0xa0afa0dc, which=op_modify,
oi=0x833c680, on=0x0) at backover.c:677
func = <value optimized out>
rc = <value optimized out>
#16 0x080e4a59 in over_op_func (op=0x83820c0, rs=0xa0afa0dc, which=op_modify) at
backover.c:730
oi = <value optimized out>
on = 0x834c270
be = <value optimized out>
db = {bd_info = 0x81f37dc, bd_self = 0x833fa60, be_ctrls =
"\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001",
'\000' <repeats 12 times>, "\001", be_flags = 2312, be_restrictops = 0,
be_requires = 0, be_ssf_set = {sss_ssf = 0,
sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0,
sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0,
sss_simple_bind = 0}, be_suffix = 0x82b8268, be_nsuffix = 0x833edc8, be_schemadn
= {bv_len = 0, bv_val = 0x0},
be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 22,
bv_val = 0x832c218 "cn=root,o=vivates,c=ch"}, be_rootndn = {bv_len = 22, bv_val
= 0x833ee10 "cn=root,o=vivates,c=ch"}, be_rootpw = {bv_len = 6, bv_val =
0x833f990 "etoile"},
be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard
= 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0,
lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0,
be_dfltaccess = ACL_READ,
be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0},
be_update_refs = 0x0, be_pending_csn_list = 0x82ecc70, be_pcl_mutex = {__data =
{__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0,
__list = {__next = 0x0}}},
__size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0x0,
be_pb =x0x0, be_cf_ocs = 0x81f5e00, be_private = 0x833fb60, be_next = {stqe_next
= 0x834bee8}}
cb = {sc_next = 0x0, sc_response = 0x80e3c90 <over_back_response>,
sc_cleanup = 0, sc_writewait = 0, sc_private = 0x833c680}
sc = <value optimized out>
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#17 0x08091371 in fe_op_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:303
update = <value optimized out>
repl_user = <value optimized out>
op_be = <value optimized out>
bd = 0x81f9000
textbuf = "\000\000\000\000\000\000\000\000h\216\257\240\362\346\b\b\001\000\000\000\001\000\000\000\"\272\031\b\000K\276)\000\000\000\000\000\000\000\000\b\222_\240(L\276)8\352,\b\020L\276)Ȏ\257\240OK\t\b\202\000\000\000X\311&\b\200\324'\b\020L\276)(L\276)\000\000\000\000Ȏ\257\240\030\000\000\000\240SQ\000\254SQ\000\001\000\000\000\320\347\b\b\240SQ\000\000\000\000\000\250\216\257\240\236m?\000\240SQ\000(\000\000\000p8\204#\364\017\030\000\000\000\000\000\000\000\000\000D\000\000\0002320\064(\232\020\000\000\000\350c,\b\000\000\000\000x\221\061\242\000\000\000\000\000\000\000\000(\217\257\240\301\016\t\b\002\000\000\000x\221\061\242\200\324'\b\020L\276)(L\276)\000\000\000\000\274\274\031\b`\222_\240\020\223_\240\000H\224^x\221\061\242(L\276)\234z\303\bD\000\000\000\320\064(\232@\222_\240"
#18 0x08091de7 in do_modify (op=0x83820c0, rs=0xa0afa0dc) at modify.c:177
dn = {bv_len = 59, bv_val = 0x8c37a02 "cn=1", '0' <repeats 12 times>,
"_O2HP,ou=Relationship,dc=HPD,o=vivates,c=ch"}
textbuf = "h\t\020\242\360{\303\b\230\237\257\240\004F7\000\022F7\000\274\306\027\000\026\000\000\000\373{\303\b\b\000\000\000\364?Q\000\211\306\027\000\364\017\030\000x\240\257\240\243\276\027\000P\t\020\242\373{C3C303\b\b\000\000\000\364?Q\000\200\240\257\240\300!8\b̠\257\240P\267>\000P\267>\000\340\237\257\240\244\203\031\b\373{\303\b\300!8\b\000\000\000\000\340\237\257\240\377\000\000\000\001\200\255\373\000\000\000\000\300!8\b\300!8\b\300!8\b\322!8\b\277\"8\b\300
8\b\350c,%5\0C004\000\020\000\210\240\257\240\371\365\f\b\000\000\000\000\350c,\bl\240\257\240",
'\000' <repeats 16 times>"\320,
\000\000\000\000\000\000\000\003\000\000\000\030\000\000\000\000\000\000\000\200u\370\267\030\241\257\240\210\240\257\240Qq\a\b\267\363\066
7 years, 7 months
Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com
Howard Chu wrote:
> ktmdms(a)gmail.com wrote:
>> --089e0115ec1091312605232ac99f
>> Content-Type: text/plain; charset=UTF-8
>>
>> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
>> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
>> generate SHA512/384 hashed passwords with no issues. What should I be
>> looking for between the two platforms that might cause the core?
>
> Strange that the kernel would make any difference - more likely it's your C
> compiler making the difference.
I may have misread your message. If the same binary works on a newer system,
that tends to imply something weird in the runtime environment. Perhaps a
problem with ASLR.
> I ran a test on one machine and got an abort in glibc saying there was a stack
> overrun. On a different machine I got no such error, and running on the
> problem system under valgrind produced no errors.
>
> On the machine that aborted, when I compiled with gcc -fstack-protector-all,
> the glibc abort disappeared as well. So, this hasn't helped me identify the
> problem yet. (gcc 4.8.4-2ubuntu1~14.04)
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 7 months
Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com
ktmdms(a)gmail.com wrote:
> --089e0115ec1091312605232ac99f
> Content-Type: text/plain; charset=UTF-8
>
> To add fuel to the fire, if I use pw-sha2 libraries that were built on a
> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
> generate SHA512/384 hashed passwords with no issues. What should I be
> looking for between the two platforms that might cause the core?
Strange that the kernel would make any difference - more likely it's your C
compiler making the difference.
I ran a test on one machine and got an abort in glibc saying there was a stack
overrun. On a different machine I got no such error, and running on the
problem system under valgrind produced no errors.
On the machine that aborted, when I compiled with gcc -fstack-protector-all,
the glibc abort disappeared as well. So, this hasn't helped me identify the
problem yet. (gcc 4.8.4-2ubuntu1~14.04)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 7 months
ITS#8223 Windows replication error
by hyc＠symas.com
> Hello,
>
> I have additional information. The problem is the entryCSN.
> User 1, which got replicated has entryCSN:
> 20150827083333.751721Z#000000#001#000000
> user 2, which got NOT replicated has entryCSN:
> 20150827083333.119585Z#000000#001#000000, which seems to be in the past
> user 3, replicated, 20150827083334.847604Z#000000#001#000000
> user 4, not replicated 20150827083334.228113Z#000000#001#000000, which
> seems to be in the past
> user 5, replicated 20150827083335.588191Z#000000#001#000000
> user 6, replicated 20150827083335.946835Z#000000#001#000000
> user 7 not replicated 20150827083335.282686Z#000000#001#000000, which
> seems to be in the past
>
> So in previous posts I got the answer, that microseconds exact time
> synchronization is only important with master master and concurrent
> writes. But now it also seems to be important with delta-synrepl.
>
> So I suppose this ITS can be closed, since it is not a bug, but worked as
> designed?
> So how to get a good enough time synchronization with windows (since the
> normal time synchronization of windows seems to be not enough)?
> Of course, if you close the ITS I can ask this question again in the
> technical list.
>
> Regards,
> Frank
ITS#8295 may be the problem here. Fixed in git master. Please test and
followup to that ticket, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 7 months
Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com
--089e0115ec1091312605232ac99f
Content-Type: text/plain; charset=UTF-8
To add fuel to the fire, if I use pw-sha2 libraries that were built on a
2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can
generate SHA512/384 hashed passwords with no issues. What should I be
looking for between the two platforms that might cause the core?
Thanks.
Kevin Martin
---
Regards,
Kevin Martin
On Tue, Oct 27, 2015 at 3:11 PM, <openldap-its(a)openldap.org> wrote:
>
> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***
>
> Thanks for your report to the OpenLDAP Issue Tracking System. Your
> report has been assigned the tracking number ITS#8294.
>
> One of our support engineers will look at your report in due course.
> Note that this may take some time because our support engineers
> are volunteers. They only work on OpenLDAP when they have spare
> time.
>
> If you need to provide additional information in regards to your
> issue report, you may do so by replying to this message. Note that
> any mail sent to openldap-its(a)openldap.org with (ITS#8294)
> in the subject will automatically be attached to the issue report.
>
> mailto:openldap-its@openldap.org?subject=(ITS#8294)
>
> You may follow the progress of this report by loading the following
> URL in a web browser:
> http://www.OpenLDAP.org/its/index.cgi?findid=8294
>
> Please remember to retain your issue tracking number (ITS#8294)
> on any further messages you send to us regarding this report. If
> you don't then you'll just waste our time and yours because we
> won't be able to properly track the report.
>
> Please note that the Issue Tracking System is not intended to
> be used to seek help in the proper use of OpenLDAP Software.
> Such requests will be closed.
>
> OpenLDAP Software is user supported.
> http://www.OpenLDAP.org/support/
>
> --------------
> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.
>
>
--089e0115ec1091312605232ac99f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To add fuel to the fire, if I use pw-sha2 libraries that w=
ere built on a 2.6 kernel (specifically=C2=A02.6.32-358.el6.x86_64) on the =
3.18 machine I can generate SHA512/384 hashed passwords with no issues.=C2=
=A0 What should I be looking for between the two platforms that might cause=
the core?<div><br></div><div>Thanks.</div><div><br></div><div>Kevin Martin=
</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D=
"gmail_signature"><div dir=3D"ltr">---<div><span style=3D"font-size:12.8px"=
><br></span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><span style=3D"font-size:12.8px">Regards,</span></div><div><div><br></di=
v><div>Kevin Martin</div></div></div></div></div>
<br><div class=3D"gmail_quote">On Tue, Oct 27, 2015 at 3:11 PM, <span dir=
=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.org" target=3D"_blank"=
>openldap-its(a)openldap.org</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><br>
*** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br>
<br>
Thanks for your report to the OpenLDAP Issue Tracking System.=C2=A0 Your<br=
>
report has been assigned the tracking number ITS#8294.<br>
<br>
One of our support engineers will look at your report in due course.<br>
Note that this may take some time because our support engineers<br>
are volunteers.=C2=A0 They only work on OpenLDAP when they have spare<br>
time.<br>
<br>
If you need to provide additional information in regards to your<br>
issue report, you may do so by replying to this message.=C2=A0 Note that<br=
>
any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@=
openldap.org</a> with (ITS#8294)<br>
in the subject will automatically be attached to the issue report.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:<a href=3D"mailto:openldap-its@openldap.=
org">openldap-its(a)openldap.org</a>?subject=3D(ITS#8294)<br>
<br>
You may follow the progress of this report by loading the following<br>
URL in a web browser:<br>
=C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D829=
4" rel=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/its/index.c=
gi?findid=3D8294</a><br>
<br>
Please remember to retain your issue tracking number (ITS#8294)<br>
on any further messages you send to us regarding this report.=C2=A0 If<br>
you don't then you'll just waste our time and yours because we<br>
won't be able to properly track the report.<br>
<br>
Please note that the Issue Tracking System is not intended to<br>
be used to seek help in the proper use of OpenLDAP Software.<br>
Such requests will be closed.<br>
<br>
OpenLDAP Software is user supported.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://www.OpenLDAP.org/support/" re=
l=3D"noreferrer" target=3D"_blank">http://www.OpenLDAP.org/support/</a><br>
<br>
--------------<br>
Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br>
<br>
</blockquote></div><br></div>
--089e0115ec1091312605232ac99f--
7 years, 7 months
(ITS#8295) Windows ldap_pvt_gettime is broken
by hyc＠openldap.org
Full_Name: Howard Chu
Version: 2.4
OS: Win32
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.155.231.14)
Submitted by: hyc
ldap_pvt_gettime is used to to generate CSNs with microsecond precision. On
Windows it goes thru some gyrations to calculate microseconds since the normal
SystemTime only has a resolution of 10-15 milliseconds. Unfortunately it doesn't
properly detect when the microsecond counter wraps around back to zero, so it
can occasionally return timestamps 1 second in the past.
7 years, 7 months
(ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com
Full_Name: Kevin Martin
Version: 2.4.42
OS: 3.8.13-55.1.6.el7uek.x86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (137.254.4.10)
Compiled 2.4.42 from source with the following configure options:
./configure --enable-ppolicy --enable-crypt --with-tls --enable-bdb
--enable-ldap --enable-slapd --enable-slapi --enable-syslog --enable-modules
compiles and installs fine. Built the pw-sha2 contrib module and installed with
no problems.
The following works fine:
/usr/local/sbin/slappasswd -v -v -v -h '{SHA256}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
/usr/local/sbin/slappasswd -v -v -v -h '{CRYPT}' -c '$6$!4&&.' -s secret
{CRYPT}$6$!4&&.$oINsiq8QMkQheQrdy0.qk7qKr7tNVNCX387QMrp8Y/w2y7JcazTvfKhG0mSGIAB1jWZ4xsDbsehH/4yPIns6I.
The following create segfaults:
/usr/local/sbin/slappasswd -v -v -v -h '{SHA384}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
Segmentation fault (core dumped)
/usr/local/sbin/slappasswd -v -v -v -h '{SHA512}' -o
module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s secret
Segmentation fault (core dumped)
I shouldn't need to use CRYPT with a salt to create a SHA512 hashed password.
Bug or something on my machine?
Regards,
Kevin Martin
7 years, 7 months
