Re: (ITS#8297) Test061 failed
by michael＠stroeder.com
hyc(a)symas.com wrote:
> Looks like a timing issue in the test script, your machine is too slow.
> test061 passes fine for me.
I also let test061 run 100 times each for hdb and mdb without an issue.
Ciao, Michael.
8 years, 1 month
Re: (ITS#8297) Test061 failed
by hyc＠symas.com
a.chelouah(a)gmail.com wrote:
> Full_Name: Abdelkader Chelouah
> Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d
> OS: RHEL 7.1
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (192.196.142.20)
>
>
> Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061
> failed for backends bdb, hdb and mdb
Looks like a timing issue in the test script, your machine is too slow.
test061 passes fine for me.
>>>>>> Starting test061-syncreplication-initiation for mdb...
> Running defines.sh
> Initializing server configurations
> Starting provider slapd on ldap://localhost:9011/
> Starting forward1 slapd on ldap://localhost:9013/
> Starting consumer slapd on ldap://localhost:9012/
> Adding schema on ldap://localhost:9011/
> Adding backend module on ldap://localhost:9011/...
> Adding schema on ldap://localhost:9012/
> Adding backend module on ldap://localhost:9012/...
> Adding schema on ldap://localhost:9013/
> Adding backend module on ldap://localhost:9013/...
> Adding database configuration on ldap://localhost:9011/
> Populating provider on ldap://localhost:9011/
> Adding database configuration on ldap://localhost:9013/
> Adding database configuration on ldap://localhost:9012/
> Using ldapsearch to check that ldap://localhost:9013/ received database...
> Using ldapsearch to check that ldap://localhost:9012/ received database...
> Waiting 1 seconds for slapd to receive database...
> Running 1 of 1 syncrepl initiation race tests...
> Stopping forwarders for add test
> Using ldapadd to add 10 entries on provider
> Starting forwarders again
> Using ldapadd to add 10 more entries on provider
> Checking replication to ldap://localhost:9013/
> Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1...
> Checking replication to ldap://localhost:9012/
> Stopping forwarders for add/delete test
> Using ldapadd to add 10 entries on provider
> Using ldapdelete to delete 10 entries on provider
> Starting forwarders again
> Using ldapadd to add 10 more entries on provider
> Using ldapdelete to delete 10 more entries on provider
> Checking replication to ldap://localhost:9013/
> Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1...
> Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17...
> Checking replication to ldap://localhost:9012/
> Stopping forwarders for delete test
> Using ldapdelete to delete entries on provider
> Starting forwarders again
> Using ldapdelete to delete 10 more entries on provider
> Checking replication to ldap://localhost:9013/
> Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21...
> Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21...
> Checking replication to ldap://localhost:9012/
> Checking contextCSN
> ERROR: contextCSN mismatch between provider and consumer
> contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000
> contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000
> Error found after 1 of 1 iterations
>>>>>> test061-syncreplication-initiation failed for mdb
> (exit 1)
> make: *** [mdb-mod] Error 1
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 1 month
Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com
--On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada
<maurizio.lattuada(a)gmail.com> wrote:
> Hello Quanah,
>
> I added the syncprov overlay to the 1st database, but is neither used
> by our application (rather than by another off-the-shelf application)
> nor replicated as is for the 2nd database.
> For your 2nd request, unfortunately I'm not able to test it, since
> between the LDAP and my test-bench application there is another server
> side application:
Ok. Is it possible to provide the custom schema you are using, and an
example of a user entry you are loading, so I can template it? I'd like to
see if I can reproduce the problem.
Thanks.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 1 month
(ITS#8298) Test061 failed
by a.chelouah＠gmail.com
Full_Name: Abdelkader Chelouah
Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d
OS: RHEL 7.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.196.142.20)
Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061
failed for backends bdb, hdb and mdb
>>>>> Starting test061-syncreplication-initiation for mdb...
Running defines.sh
Initializing server configurations
Starting provider slapd on ldap://localhost:9011/
Starting forward1 slapd on ldap://localhost:9013/
Starting consumer slapd on ldap://localhost:9012/
Adding schema on ldap://localhost:9011/
Adding backend module on ldap://localhost:9011/...
Adding schema on ldap://localhost:9012/
Adding backend module on ldap://localhost:9012/...
Adding schema on ldap://localhost:9013/
Adding backend module on ldap://localhost:9013/...
Adding database configuration on ldap://localhost:9011/
Populating provider on ldap://localhost:9011/
Adding database configuration on ldap://localhost:9013/
Adding database configuration on ldap://localhost:9012/
Using ldapsearch to check that ldap://localhost:9013/ received database...
Using ldapsearch to check that ldap://localhost:9012/ received database...
Waiting 1 seconds for slapd to receive database...
Running 1 of 1 syncrepl initiation race tests...
Stopping forwarders for add test
Using ldapadd to add 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1...
Checking replication to ldap://localhost:9012/
Stopping forwarders for add/delete test
Using ldapadd to add 10 entries on provider
Using ldapdelete to delete 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Using ldapdelete to delete 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1...
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17...
Checking replication to ldap://localhost:9012/
Stopping forwarders for delete test
Using ldapdelete to delete entries on provider
Starting forwarders again
Using ldapdelete to delete 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21...
Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21...
Checking replication to ldap://localhost:9012/
Checking contextCSN
ERROR: contextCSN mismatch between provider and consumer
contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000
contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000
Error found after 1 of 1 iterations
>>>>> test061-syncreplication-initiation failed for mdb
(exit 1)
make: *** [mdb-mod] Error 1
8 years, 1 month
(ITS#8297) Test061 failed
by a.chelouah＠gmail.com
Full_Name: Abdelkader Chelouah
Version: OPENLDAP_REL_ENG_2_4 f57ec1dff4a440dbab4c9ad55631ef929ca8713d
OS: RHEL 7.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.196.142.20)
Last git branch OPENLDAP_REL_ENG_2_4 build from source under RHEL 7.1. Test061
failed for backends bdb, hdb and mdb
>>>>> Starting test061-syncreplication-initiation for mdb...
Running defines.sh
Initializing server configurations
Starting provider slapd on ldap://localhost:9011/
Starting forward1 slapd on ldap://localhost:9013/
Starting consumer slapd on ldap://localhost:9012/
Adding schema on ldap://localhost:9011/
Adding backend module on ldap://localhost:9011/...
Adding schema on ldap://localhost:9012/
Adding backend module on ldap://localhost:9012/...
Adding schema on ldap://localhost:9013/
Adding backend module on ldap://localhost:9013/...
Adding database configuration on ldap://localhost:9011/
Populating provider on ldap://localhost:9011/
Adding database configuration on ldap://localhost:9013/
Adding database configuration on ldap://localhost:9012/
Using ldapsearch to check that ldap://localhost:9013/ received database...
Using ldapsearch to check that ldap://localhost:9012/ received database...
Waiting 1 seconds for slapd to receive database...
Running 1 of 1 syncrepl initiation race tests...
Stopping forwarders for add test
Using ldapadd to add 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to receive entry 1...
Checking replication to ldap://localhost:9012/
Stopping forwarders for add/delete test
Using ldapadd to add 10 entries on provider
Using ldapdelete to delete 10 entries on provider
Starting forwarders again
Using ldapadd to add 10 more entries on provider
Using ldapdelete to delete 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 1...
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 17...
Checking replication to ldap://localhost:9012/
Stopping forwarders for delete test
Using ldapdelete to delete entries on provider
Starting forwarders again
Using ldapdelete to delete 10 more entries on provider
Checking replication to ldap://localhost:9013/
Waiting 1 seconds for ldap://localhost:9013/ to delete entry 21...
Waiting 2 seconds for ldap://localhost:9013/ to delete entry 21...
Checking replication to ldap://localhost:9012/
Checking contextCSN
ERROR: contextCSN mismatch between provider and consumer
contextCSN on provider: contextCSN: 20151028183903.538313Z#000000#001#000000
contextCSN on consumer: contextCSN: 20151028183902.812955Z#000000#001#000000
Error found after 1 of 1 iterations
>>>>> test061-syncreplication-initiation failed for mdb
(exit 1)
make: *** [mdb-mod] Error 1
8 years, 1 month
Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com
Hello Quanah,
I added the syncprov overlay to the 1st database, but is neither used
by our application (rather than by another off-the-shelf application)
nor replicated as is for the 2nd database.
For your 2nd request, unfortunately I'm not able to test it, since
between the LDAP and my test-bench application there is another server
side application:
Test-bench_application --> spring_http_invoker --> Server_side_app
---> data_for_db_2 ---> LDAP ---> data_from_db_2 --->
App_in_syncprov_with_ldap
I don't have the control over the section "server_side_app --->
data_for_db_2 ---> LDAP".
Anyway, as said above, now I enabled the syncprov over both databases:
--- begin slapd.conf ---
database bdb
suffix "o=3Dorgname,c=3Dat"
checkpoint 1024 15
rootdn "cn=3Droot,o=3Dorgname,c=3Dat"
rootpw XYZ
directory /var/lib/ldap
index entryCSN eq
index entryUUID eq
overlay syncprov
syncprov-checkpoint 1000 10
syncprov-sessionlog 1000
syncprov-reloadhint TRUE
syncprov-nopresent FALSE
database bdb
suffix "o=3Dvivates,c=3Dch"
checkpoint 1024 15
rootdn "cn=3Droot,o=3Dvivates,c=3Dch"
rootpw XXX
directory /var/lib/ldap-hpd
index entryCSN eq
index entryUUID eq
overlay unique
unique_attributes hcIdentifier
overlay syncprov
syncprov-checkpoint 1000 10
syncprov-sessionlog 1000
syncprov-reloadhint TRUE
syncprov-nopresent FALSE
--- end slapd.conf ---
but unfortunately I had the same issue (as usual, I restarted the
server before debugging SLAPD).
Please note: if I keep stopped the application that is in syncprov
with LDAP ("App_in_syncprov_with_ldap" on the schema above), I load
all the entries in the 2nd database, then I turn that application on,
then slapd works flawless and the (offline) synchronization is done
right.
--- begin gdb session ---
top - 08:56:12 up 4 min, 2 users, load average: 0.09, 0.27, 0.14
Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.5%us, 0.5%sy, 0.0%ni, 99.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0=
%st
Mem: 4019472k total, 2928668k used, 1090804k free, 56080k buffers
Swap: 2064380k total, 0k used, 2064380k free, 1572400k cached
[root@ibb0301 .libs]# pwd
/root/src_openldap/openldap/servers/slapd/.libs
[root@ibb0301 .libs]# ./slapd -VVV
@(#) $OpenLDAP: slapd 2.4.X (Oct 30 2015 08:49:20) $
root@ibb0301:/root/src_openldap/openldap/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 version 3 or later <http://gnu.org/licenses/gpl.htm=
l>
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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/root/src_openldap/openldap/servers/slapd/.libs/slapd...done.
(gdb) run -d 1 -h ldap://
Starting program:
/root/src_openldap/openldap/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
56332204 @(#) $OpenLDAP: slapd 2.4.X (Oct 30 2015 08:49:20) $
root@ibb0301:/root/src_openldap/openldap/servers/slapd
ldap_pvt_gethostbyname_a: host=3Dibb0301, r=3D0
56332204 daemon_init: listen on ldap://
56332204 daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://)
56332204 daemon: listener initialized ldap://
56332204 daemon_init: 2 listeners opened
56332205 slapd init: initiated server.
56332205 slap_sasl_init: initialized!
56332205 bdb_back_initialize: initialize BDB backend
56332205 bdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015)
56332205 hdb_back_initialize: initialize HDB backend
56332205 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015)
56332205 mdb_back_initialize: initialize MDB backend
56332205 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015)
56332205 backend_startup_one: starting "cn=3Dconfig"
56332205 ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=3Dconfi=
g.ldif"
CUT CUT CUT
56332764 connection_get(19): got connid=3D1000
56332764 connection_read(19): checking for input on id=3D1000
ber_get_next
ber_get_next: tag 0x30 len 192 contents:
56332764 op tag 0x66, time 1446192996
ber_get_next
56332764 conn=3D1000 op=3D45578 do_modify
ber_scanf fmt ({m) ber:
ber_scanf fmt ({e{m[W]}}) ber:
56332764 =3D> get_ctrls
ber_scanf fmt ({m) ber:
56332764 =3D> get_ctrls: oid=3D"2.16.840.1.113730.3.4.2" (noncritical)
56332764 <=3D get_ctrls: n=3D1 rc=3D0 err=3D""
56332764 >>> dnPrettyNormal:
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>
56332764 <<< dnPrettyNormal:
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>,
<cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch>
56332764 >>> dnPretty: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3Dviv=
ates,c=3Dch>
56332764 <<< dnPretty: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3Dviv=
ates,c=3Dch>
56332764 >>> dnNormalize: <cn=3Dentry.xxx,ou=3DHCProfessional,dc=3DHPD,o=3D=
vivates,c=3Dch>
56332764 <<< dnNormalize: <cn=3Dentry.xxx,ou=3Dhcprofessional,dc=3Dhpd,o=3D=
vivates,c=3Dch>
56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=
=3Dvivates,c=3Dch")
56332764 bdb_entry_get: rc=3D0
56332764 syncprov_matchops: sid 000 fscope 1 rc 6
56332764 =3D=3D> unique_modify
<cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch>
56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=
=3Dvivates,c=3Dch")
56332764 bdb_entry_get: rc=3D0
56332764 unique_modify: administrative bypass, skipping
56332764 bdb_modify: txn1 id: 80005ad3
56332764 bdb_dn2entry("cn=3D1000000000000_o2hp,ou=3Drelationship,dc=3Dhpd,o=
=3Dvivates,c=3Dch")
56332764 bdb_modify: txn2 id: 80005ad4
56332764 bdb_modify_internal: 0x00000288:
cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch
56332764 oc_check_required entry
(cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch),
objectClass "VivatesHCRelationship"
56332764 oc_check_allowed type "relationshipType"
56332764 oc_check_allowed type "owner"
56332764 oc_check_allowed type "objectClass"
56332764 oc_check_allowed type "cn"
56332764 oc_check_allowed type "member"
56332764 oc_check_allowed type "structuralObjectClass"
56332764 oc_check_allowed type "entryUUID"
56332764 oc_check_allowed type "creatorsName"
56332764 oc_check_allowed type "createTimestamp"
56332764 oc_check_allowed type "entryCSN"
56332764 oc_check_allowed type "modifiersName"
56332764 oc_check_allowed type "modifyTimestamp"
56332764 =3D> key_change(DELETE,288)
56332764 <=3D key_change 0
56332764 =3D> key_change(ADD,288)
56332764 <=3D key_change 0
56332764 =3D> entry_encode(0x00000288):
cn=3D1000000000000_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch
56332764 ch_malloc of 824480 bytes failed
slapd: ch_malloc.c:57: ch_malloc: Assertion `0' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xa01f8b70 (LWP 2339)]
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 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.=
c:64
#2 0x003ab14a in abort () at abort.c:92
#3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:96
#4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:105
#5 0x0809470a in ch_malloc (size=3D824480) at ch_malloc.c:57
#6 0x08082b71 in entry_encode (e=3D0xa01f6bac, bv=3D0xa01f6a14) at entry.c=
:710
#7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>,
tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at
id2entry.c:54
#8 0x080f1b0c in bdb_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c=
:712
#9 0x080e41f3 in overlay_op_walk (op=3D0xa21b62d8, rs=3D0xa01f80dc,
which=3Dop_modify, oi=3D0x833f368, on=3D0x0) at backover.c:677
#10 0x080e4cd9 in over_op_func (op=3D0xa21b62d8, rs=3D0xa01f80dc,
which=3Dop_modify) at backover.c:730
#11 0x08091561 in fe_op_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify=
.c:303
#12 0x08091fd7 in do_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c:=
177
#13 0x080784ac in connection_operation (ctx=3D0xa01f81ec,
arg_v=3D0xa21b62d8) at connection.c:1158
#14 0x08078d47 in connection_read_thread (ctx=3D0xa01f81ec, argv=3D0x13)
at connection.c:1294
#15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool=
.c:696
#16 0x0036ab39 in start_thread (arg=3D0xa01f8b70) at pthread_create.c:301
#17 0x00461c2e 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 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.=
c:64
resultvar =3D <value optimized out>
resultvar =3D <value optimized out>
pid =3D 5312500
selftid =3D 2339
#2 0x003ab14a in abort () at abort.c:92
save_stage =3D 2
act =3D {__sigaction_handler =3D {sa_handler =3D 0xbe728f38,
sa_sigaction =3D 0xbe728f38}, sa_mask =3D {__val =3D {5312500, 64, 1,
4125602, 2686412784, 0, 104, 57, 2718957584, 5312500, 57, 56,
2686412956, 4097042, 3195178816, 57, 2686412996, 3195178816, 0,
4222451712,
3195178816, 3195178816, 3195178816, 3195178816,
3195178872, 3195178916, 3195178816, 3195178916, 0, 0, 0, 0}}, sa_flags
=3D 0, sa_restorer =3D 0x4d54d8 <_libc_intl_domainname>}
sigs =3D {__val =3D {32, 0 <repeats 31 times>}}
#3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:96
str =3D 0xbe728f40 ""
total =3D 4096
#4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:105
No locals.
#5 0x0809470a in ch_malloc (size=3D824480) at ch_malloc.c:57
new =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "ch_malloc"
#6 0x08082b71 in entry_encode (e=3D0xa01f6bac, bv=3D0xa01f6a14) at entry.c=
:710
len =3D 824480
dnlen =3D 59
ndnlen =3D 59
i =3D <value optimized out>
nattrs =3D <value optimized out>
nvals =3D <value optimized out>
a =3D <value optimized out>
ptr =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "entry_encode"
#7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>,
tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at
id2entry.c:54
bdb =3D <value optimized out>
db =3D 0x82c5848
key =3D {data =3D 0xa01f6a1c, size =3D 4, ulen =3D 0, dlen =3D 0, d=
off =3D
0, app_data =3D 0x0, flags =3D 0}
data =3D {data =3D 0x1, size =3D 137288968, ulen =3D 0, dlen =3D
2638157064, doff =3D 2686413844, app_data =3D 0x0, flags =3D 2638157064}
bv =3D {bv_len =3D 824480, bv_val =3D 0x37c57660 "cn=3Droot,o=3Dviv=
ates,c=3Dch"}
rc =3D <value optimized out>
nid =3D 2281832448
#8 0x080f1b0c in bdb_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c=
:712
bdb =3D 0x833fbe0
e =3D 0x8373a64
ei =3D 0x83e08b0
manageDSAit =3D 2
textbuf =3D
"\377\023\000\000\233\353\064\242\000\000\000\000\000\000\000\000\024\061\2=
13\000\330b\033\242\274\070\037\b8l\037\240,\032\213\000\330b\033\242d:7\b\=
000\000\000\000\210\316\064\b",
'\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>,
"\026\000\000\000X\353\064\242\026\000\000\000\210\316\064\b\000\000\000\00=
0\000\000\000\000<k\037\240",
'\000' <repeats 20 times>"\220,
\317\064\b\000\000\000\000\000\000\000\000\300s=CF=9F\260c\033\242f\000\000=
\000d'3V\a\000\000\000\260l\037\240;\000\000\000`r=CF=9F;\000\000\000\020s=
=CF=9F\350.\335j",
'\000' <repeats 71 times>
ltid =3D 0x9d3f1508
lt2 =3D 0x9d3136d0
opinfo =3D {boi_oe =3D {oe_next =3D {sle_next =3D 0x0}, oe_key =3D
0x833fbe0}, boi_txn =3D 0x9d3f1508, boi_locks =3D 0x0, boi_err =3D 0,
boi_acl_cache =3D 0 '\000', boi_flag =3D 0 '\000'}
dummy =3D {e_id =3D 648, e_name =3D {bv_len =3D 59, bv_val =3D 0x83=
e1470
"cn=3D1", '0' <repeats 12 times>,
"_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}, e_nname =3D {bv_len=
=3D
59,
bv_val =3D 0x83e0700 "cn=3D1", '0' <repeats 12 times>,
"_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch"}, e_attrs =3D 0xbc17e=
c14,
e_ocflags =3D 65792, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D
0x83e08b0}
lock =3D {off =3D 120504, ndx =3D 605, gen =3D 11022, mode =3D DB_L=
OCK_READ}
num_retries =3D 0
preread_ctrl =3D 0x0
postread_ctrl =3D 0x0
ctrls =3D {0x0, 0x16, 0x9ef978e8, 0x0, 0x0, 0x0}
num_ctrls =3D 0
rc =3D <value optimized out>
#9 0x080e41f3 in overlay_op_walk (op=3D0xa21b62d8, rs=3D0xa01f80dc,
which=3Dop_modify, oi=3D0x833f368, on=3D0x0) at backover.c:677
func =3D <value optimized out>
rc =3D <value optimized out>
#10 0x080e4cd9 in over_op_func (op=3D0xa21b62d8, rs=3D0xa01f80dc,
which=3Dop_modify) at backover.c:730
oi =3D <value optimized out>
on =3D 0x834cc78
be =3D <value optimized out>
---Type <return> to continue, or q <return> to quit---
db =3D {bd_info =3D 0x81f329c, bd_self =3D 0x834c400, be_ctrls =3D
"\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\0=
00\001",
'\000' <repeats 12 times>, "\001", be_flags =3D 2312, be_restrictops =3D
0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0,
sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0,
sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0,
sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x82b1f10,
be_nsuffix =3D 0x834c500, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0},
be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D
{bv_len =3D 22, bv_val =3D 0x8301ea0 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_ro=
otndn
=3D {bv_len =3D 22, bv_val =3D 0x834c548 "cn=3Droot,o=3Dvivates,c=3Dch"},
be_rootpw =3D {bv_len =3D 6, bv_val =3D 0x8340368 "etoile"},
be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600,
lms_t_hard =3D 0, lms_s_soft =3D 500, lms_s_hard =3D 0, lms_s_unchecked =3D
-1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =
=3D
0x0, be_acl =3D 0x0, be_dfltaccess =3D ACL_READ,
be_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val =
=3D
0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x82ed968,
be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __owner =3D 0, _=
_kind
=3D 0, __nusers =3D 0, {__spins =3D 0, __list =3D {__next =3D 0x0}}},
__size =3D '\000' <repeats 23 times>, __align =3D 0},
be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x81f58c0, be_private =3D
0x833fbe0, be_next =3D {stqe_next =3D 0x834c8e0}}
cb =3D {sc_next =3D 0x0, sc_response =3D 0x80e3f10
<over_back_response>, sc_cleanup =3D 0, sc_writewait =3D 0, sc_private =3D
0x833f368}
sc =3D <value optimized out>
rc =3D 32768
__PRETTY_FUNCTION__ =3D "over_op_func"
#11 0x08091561 in fe_op_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify=
.c:303
update =3D <value optimized out>
repl_user =3D <value optimized out>
op_be =3D <value optimized out>
bd =3D 0x81f8ac0
textbuf =3D
"\000\000\000\000\000\000\000\000hn\037\240\342\350\b\b\001\000\000\000\001=
\000\000\000b\300\031\b\bs\275\237\000\000\000\000\000\000\000\000\br=CF=9F=
\220\201Z\274\270\355,\b\340\203Z\274\310n\037\240?M\t\b\002\000\000\000X\3=
11&\b\200\324'\b\340\203Z\274\220\201Z\274\000\000\000\000\310n\037\240\030=
\000\000\000\020\000\020\242\034\000\020\242\001\000\000\000\300\351\b\b\02=
0\000\020\242\000\000\000\000\250n\037\240\236=3D?\000\020\000\020\242\030\=
000\000\000\210\201Z\274$\346\027\000\000\000\000\000\000\000\000\000I\000\=
000\000\360`\275\237\020\000\000\000\270\302\032\242\000\000\000\000\210\36=
0\062\242\000\000\000\000\000\000\000\000(o\037\240\261\020\t\b\002\000\000=
\000\210\360\062\242\200\324'\b\340\203Z\274\220\201Z\274\000\000\000\000\3=
74\302\031\b`r=CF=9F\020s=CF=9F\350.\335j\210\360\062\242\220\201Z\274\241\=
204Z\274I\000\000\000\360`\275\237@r=CF=9F"
#12 0x08091fd7 in do_modify (op=3D0xa21b62d8, rs=3D0xa01f80dc) at modify.c:=
177
dn =3D {bv_len =3D 59, bv_val =3D 0xbc5a8402 "cn=3D1", '0' <repeats=
12
times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}
textbuf =3D
"\001\000\000\000\201\000\000\000\346\033G\000\250\177\037\240\370\004\060\=
242\000\262\205\273\250\177\037\240\004\026\067\000\022\026\067\000\233\275=
\027\000\023\000\000\000\v\262\205\273\b\000\000\000\374\200\037\240\330c\0=
33\242$\346\027\000x\200\037\240\352\256\027\000\340\004\060\242\v\262\205\=
273\b\000\000\000P\207>\000P\207>\000\340\177\037\240\344\211\031\b\374\200=
\037\240\330c\033\242\000\000\000\000\340\177\037\240\377\000\000\000\001\2=
00\255\373\000\000\000\000\330c\033\242\330c\033\242\330c\033\242\352c\033\=
242\327d\033\242\330b\033\242\270\302\032\242\004\000\020\000\210\200\037\2=
40)\370\f\b\000\000\000\000\270\302\032\242l\200\037\240\000\000\000\000HW\=
356\006\000\000\000\000\000\000\000\000^V\027\000\354\201\037\240Xe\033\242=
\031\000\000\000\000\000\000\000d\240\370\267\030\201\037\240\210\200\037\2=
40As\a\b\267\303\066\000\020s\a\b#\t\000\000\274\020\027\000d\240\370\267d\=
240",
<incomplete sequence \370\267>
tmp =3D <value optimized out>
#13 0x080784ac in connection_operation (ctx=3D0xa01f81ec,
arg_v=3D0xa21b62d8) at connection.c:1158
rc =3D 80
cancel =3D <value optimized out>
op =3D 0xa21b62d8
rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, sr_er=
r =3D
0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0,
sr_un =3D {sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0,
r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D
0x0},
sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =
=3D
0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}
tag =3D 102
opidx =3D SLAP_OP_MODIFY
conn =3D 0xb7f8a064
memctx =3D 0xa21ac2b8
memctx_null =3D 0x0
memsiz =3D 1048576
__PRETTY_FUNCTION__ =3D "connection_operation"
#14 0x08078d47 in connection_read_thread (ctx=3D0xa01f81ec, argv=3D0x13)
at connection.c:1294
cri =3D {op =3D 0xa21b62d8, func =3D 0, arg =3D 0x0, ctx =3D 0xa01f=
81ec,
nullop =3D 0}
s =3D 19
#15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool=
.c:696
pool =3D 0x8287b80
task =3D 0xa2d00518
work_list =3D <value optimized out>
ctx =3D {ltu_id =3D 2686421872, ltu_key =3D {{ltk_key =3D 0x8077310=
,
ltk_data =3D 0xa21abbb0, ltk_free =3D 0x80773e0 <conn_counter_destroy>},
{ltk_key =3D 0x80cf660, ltk_data =3D 0xa21ac2b8, ltk_free =3D 0x80cf690
<slap_sl_mem_destroy>}, {ltk_key =3D 0x82ed978,
ltk_data =3D 0xa21ab928, ltk_free =3D 0x81336b0
<bdb_reader_free>}, {ltk_key =3D 0x808c910, ltk_data =3D 0x0, ltk_free =3D
0x808c720 <slap_op_q_destroy>}, {ltk_key =3D 0x80f6260, ltk_data =3D
0x9f2ff008, ltk_free =3D 0x80f6320 <search_stack_free>}, {ltk_key =3D 0x0,
ltk_data =3D 0x0, ltk_free =3D 0} <repeats 27 times>}}
kctx =3D <value optimized out>
keyslot =3D 602
hash =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"
#16 0x0036ab39 in start_thread (arg=3D0xa01f8b70) at pthread_create.c:301
__res =3D <value optimized out>
__ignore1 =3D 2339
__ignore2 =3D 6
pd =3D 0xa01f8b70
now =3D <value optimized out>
unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {3653620, 0,
4001536, -1608547176, 1573480548, 261634852}, mask_was_saved =3D 0}},
priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D=
0x0,
canceltype =3D 0}}}
not_first_call =3D <value optimized out>
pagesize_m1 =3D <value optimized out>
sp =3D <value optimized out>
freesize =3D <value optimized out>
#17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
---Type <return> to continue, or q <return> to quit---
No locals.
--- end gdb session ---
Cheers,
Maurizio
2015-10-29 23:00 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> --On Thursday, October 29, 2015 11:25 AM +0100 Maurizio Lattuada
> <maurizio.lattuada(a)gmail.com> wrote:
>
>> Hello Quanah,
>> thanks for the hint.
>>
>> I cloned the repository and checked out the branch you told me:
>>
>> [root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4
>> Already on 'OPENLDAP_REL_ENG_2_4'
>> [root@ibb0301 openldap]# git branch
>> * OPENLDAP_REL_ENG_2_4
>> master
>>
>> Then, after compiling the whole stuff, I started it as usual with GDB
>> and with my client application active (synch via syncprov).
>> Here again I got a failure due to failed malloc (returns NULL). As
>> that moment, the %MEM shown by top was about 66% (it increased till
>> here up to 1% every 10s). Please consider that, before starting gdb, I
>> rebooted my server (4 GB RAM, 2 GB swap)
>
>
> If you add syncprov overlay to the other data db, do you have the same
> issue?
>
> Also, if you make it a single DB (using a suffix of "") rather than two
> distinct DBs, do you still hit the issue?
>
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--=20
Maurizio Lattuada
8 years, 1 month
Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com
--On Thursday, October 29, 2015 11:25 AM +0100 Maurizio Lattuada
<maurizio.lattuada(a)gmail.com> wrote:
> Hello Quanah,
> thanks for the hint.
>
> I cloned the repository and checked out the branch you told me:
>
> [root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4
> Already on 'OPENLDAP_REL_ENG_2_4'
> [root@ibb0301 openldap]# git branch
> * OPENLDAP_REL_ENG_2_4
> master
>
> Then, after compiling the whole stuff, I started it as usual with GDB
> and with my client application active (synch via syncprov).
> Here again I got a failure due to failed malloc (returns NULL). As
> that moment, the %MEM shown by top was about 66% (it increased till
> here up to 1% every 10s). Please consider that, before starting gdb, I
> rebooted my server (4 GB RAM, 2 GB swap)
If you add syncprov overlay to the other data db, do you have the same
issue?
Also, if you make it a single DB (using a suffix of "") rather than two
distinct DBs, do you still hit the issue?
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
8 years, 1 month
Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com
Hello Quanah,
thanks for the hint.
I cloned the repository and checked out the branch you told me:
[root@ibb0301 openldap]# git checkout OPENLDAP_REL_ENG_2_4
Already on 'OPENLDAP_REL_ENG_2_4'
[root@ibb0301 openldap]# git branch
* OPENLDAP_REL_ENG_2_4
master
Then, after compiling the whole stuff, I started it as usual with GDB
and with my client application active (synch via syncprov).
Here again I got a failure due to failed malloc (returns NULL). As
that moment, the %MEM shown by top was about 66% (it increased till
here up to 1% every 10s). Please consider that, before starting gdb, I
rebooted my server (4 GB RAM, 2 GB swap)
This is the GDB trace:
--- begin gdb ---
root@ibb0301 .libs]# pwd
/root/src_openldap/openldap/servers/slapd/.libs
[root@ibb0301 .libs]# ./slapd -VVV
@(#) $OpenLDAP: slapd 2.4.X (Oct 29 2015 09:45:56) $
root@ibb0301:/root/src_openldap/openldap/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 version 3 or later <http://gnu.org/licenses/gpl.htm=
l>
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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/root/src_openldap/openldap/servers/slapd/.libs/slapd...done.
(gdb) run -d 1 -h ldap://
Starting program:
/root/src_openldap/openldap/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
5631e005 @(#) $OpenLDAP: slapd 2.4.X (Oct 29 2015 09:45:56) $
root@ibb0301:/root/src_openldap/openldap/servers/slapd
ldap_pvt_gethostbyname_a: host=3Dibb0301, r=3D0
5631e005 daemon_init: listen on ldap://
5631e005 daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://)
5631e005 daemon: listener initialized ldap://
5631e005 daemon_init: 2 listeners opened
5631e005 slapd init: initiated server.
5631e006 slap_sasl_init: initialized!
5631e006 bdb_back_initialize: initialize BDB backend
5631e006 bdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015)
5631e006 hdb_back_initialize: initialize HDB backend
5631e006 hdb_back_initialize: Berkeley DB 4.7.25: (September 22, 2015)
5631e006 mdb_back_initialize: initialize MDB backend
5631e006 mdb_back_initialize: LMDB 0.9.16: (August 14, 2015)
5631e006 backend_startup_one: starting "cn=3Dconfig"
5631e006 ldif_read_file: read entry file: "/etc/openldap/slapd.d/cn=3Dconfi=
g.ldif"
CUT CUT CUT
5631e3d6 connection_get(20): got connid=3D1001
5631e3d6 connection_read(20): checking for input on id=3D1001
ber_get_next
ber_get_next: tag 0x30 len 123 contents:
5631e3d6 op tag 0x63, time 1446110166
ber_get_next
5631e3d6 conn=3D1001 op=3D270855 do_search
ber_scanf fmt ({miiiib) ber:
5631e3d6 >>> dnPrettyNormal: <cn=3DClaus
Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>
5631e3d6 <<< dnPrettyNormal: <cn=3DClaus
Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>,
<cn=3Dclaus petersmann.7601000757517,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivat=
es,c=3Dch>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
5631e3d6 =3D> bdb_search
5631e3d6 bdb_dn2entry("cn=3Dclaus
petersmann.7601000757517,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch")
5631e3d6 =3D> send_search_entry: conn 1001 dn=3D"cn=3DClaus
Petersmann.7601000757517,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch"
ber_flush2: 141 bytes to sd 20
5631e3d6 <=3D send_search_entry: conn 1001 exit.
5631e3d6 send_ldap_result: conn=3D1001 op=3D270855 p=3D3
5631e3d6 send_ldap_response: msgid=3D270856 tag=3D101 err=3D0
ber_flush2: 16 bytes to sd 20
5631e3d6 connection_get(20): got connid=3D1001
5631e3d6 connection_read(20): checking for input on id=3D1001
ber_get_next
ber_get_next: tag 0x30 len 121 contents:
5631e3d6 op tag 0x63, time 1446110166
ber_get_next
5631e3d6 conn=3D1001 op=3D270856 do_search
ber_scanf fmt ({miiiib) ber:
5631e3d6 >>> dnPrettyNormal: <cn=3DRudolf
Beutler.7601000313430,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>
5631e3d6 <<< dnPrettyNormal: <cn=3DRudolf
Beutler.7601000313430,ou=3DHCProfessional,dc=3DHPD,o=3Dvivates,c=3Dch>,
<cn=3Drudolf beutler.7601000313430,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates=
,c=3Dch>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
5631e3d6 =3D> bdb_search
5631e3d6 bdb_dn2entry("cn=3Drudolf
beutler.7601000313430,ou=3Dhcprofessional,dc=3Dhpd,o=3Dvivates,c=3Dch")
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x9fffcb70 (LWP 3039)]
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 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.=
c:64
#2 0x003ab14a in abort () at abort.c:92
#3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:96
#4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:105
#5 0x0809470a in ch_malloc (size=3D825230) at ch_malloc.c:57
#6 0x08082b71 in entry_encode (e=3D0x9fffabac, bv=3D0x9fffaa14) at entry.c=
:710
#7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>,
tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at
id2entry.c:54
#8 0x080f1b0c in bdb_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c=
:712
#9 0x080e41f3 in overlay_op_walk (op=3D0xa2d03098, rs=3D0x9fffc0dc,
which=3Dop_modify, oi=3D0x833ca00, on=3D0x0) at backover.c:677
#10 0x080e4cd9 in over_op_func (op=3D0xa2d03098, rs=3D0x9fffc0dc,
which=3Dop_modify) at backover.c:730
#11 0x08091561 in fe_op_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify=
.c:303
#12 0x08091fd7 in do_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c:=
177
#13 0x080784ac in connection_operation (ctx=3D0x9fffc1ec,
arg_v=3D0xa2d03098) at connection.c:1158
#14 0x08078d47 in connection_read_thread (ctx=3D0x9fffc1ec, argv=3D0x15)
at connection.c:1294
#15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool=
.c:696
#16 0x0036ab39 in start_thread (arg=3D0x9fffcb70) at pthread_create.c:301
#17 0x00461c2e 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 0x003a9871 in raise (sig=3D6) at ../nptl/sysdeps/unix/sysv/linux/raise.=
c:64
resultvar =3D <value optimized out>
resultvar =3D <value optimized out>
pid =3D 5312500
selftid =3D 3039
#2 0x003ab14a in abort () at abort.c:92
save_stage =3D 2
act =3D {__sigaction_handler =3D {sa_handler =3D 0x5a5ebb30,
sa_sigaction =3D 0x5a5ebb30}, sa_mask =3D {__val =3D {5312500, 64, 1,
4125602, 2684332016, 0, 104, 57, 5317536, 5312500, 57, 56, 2684332188,
4097042, 1516157752, 57, 2684332228, 1516157752, 0, 4222451712,
1516157752, 1516157752, 1516157752, 1516157752,
1516157808, 1516157852, 1516157752, 1516157852, 0, 0, 0, 0}}, sa_flags
=3D 0, sa_restorer =3D 0x4d54d8 <_libc_intl_domainname>}
sigs =3D {__val =3D {32, 0 <repeats 31 times>}}
#3 0x003a2b8b in __assert_fail_base (fmt=3D0x4d7d58 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:96
str =3D 0x5a5ebb38 ""
total =3D 4096
#4 0x003a2c46 in __assert_fail (assertion=3D0x81b75e9 "0",
file=3D0x819d0e7 "ch_malloc.c", line=3D57, function=3D0x819d17f "ch_malloc"=
)
at assert.c:105
No locals.
#5 0x0809470a in ch_malloc (size=3D825230) at ch_malloc.c:57
new =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "ch_malloc"
#6 0x08082b71 in entry_encode (e=3D0x9fffabac, bv=3D0x9fffaa14) at entry.c=
:710
len =3D 825230
dnlen =3D 59
ndnlen =3D 59
i =3D <value optimized out>
nattrs =3D <value optimized out>
nvals =3D <value optimized out>
a =3D <value optimized out>
ptr =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "entry_encode"
#7 0x0813e2d5 in bdb_id2entry_put (be=3D<value optimized out>,
tid=3D<value optimized out>, e=3D<value optimized out>, flag=3D0) at
id2entry.c:54
bdb =3D <value optimized out>
db =3D 0x82c5100
key =3D {data =3D 0x9fffaa1c, size =3D 4, ulen =3D 0, dlen =3D 0, d=
off =3D
0, app_data =3D 0x0, flags =3D 0}
data =3D {data =3D 0x1, size =3D 137287120, ulen =3D 0, dlen =3D
50242672, doff =3D 2684333076, app_data =3D 0x0, flags =3D 50242672}
bv =3D {bv_len =3D 825230, bv_val =3D 0x57bb64d0 "cn=3Droot,o=3Dviv=
ates,c=3Dch"}
rc =3D <value optimized out>
nid =3D 2281832448
#8 0x080f1b0c in bdb_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c=
:712
bdb =3D 0x833fee0
e =3D 0x8373224
ei =3D 0xa21e34c8
manageDSAit =3D 2
textbuf =3D
"\377\023\000\000\363\257\021\242\000\000\000\000\000\000\000\000\024\061\2=
13\000\230\060=D0=A2\274\070\037\b8\254\377\237,\032\213\000\230\060=D0=A2$=
27\b\000\000\000\000\240\001\064\b",
'\000' <repeats 16 times>"\200, ", '\000' <repeats 11 times>,
"\026\000\000\000\260\257\021\242\026\000\000\000\240\001\064\b\000\000\000=
\000\000\000\000\000<\253\377\237",
'\000' <repeats 20 times>"\300,
\002\064\b\000\000\000\000\000\000\000\000\300\263\257\237p1=D0=A2f\000\000=
\000\323\343\061VM\000\000\000\260\254\377\237;\000\000\000`\262\257\237;\0=
00\000\000\020\263\257\237
\273\372", '\000' <repeats 72 times>
---Type <return> to continue, or q <return> to quit---
ltid =3D 0x2fea470
lt2 =3D 0x2fea508
opinfo =3D {boi_oe =3D {oe_next =3D {sle_next =3D 0x0}, oe_key =3D
0x833fee0}, boi_txn =3D 0x2fea470, boi_locks =3D 0x0, boi_err =3D 0,
boi_acl_cache =3D 0 '\000', boi_flag =3D 0 '\000'}
dummy =3D {e_id =3D 648, e_name =3D {bv_len =3D 59, bv_val =3D
0xa21e48a0 "cn=3D1", '0' <repeats 12 times>,
"_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}, e_nname =3D {bv_len=
=3D
59,
bv_val =3D 0xa21e48e0 "cn=3D1", '0' <repeats 12 times>,
"_o2hp,ou=3Drelationship,dc=3Dhpd,o=3Dvivates,c=3Dch"}, e_attrs =3D 0x34877=
abc,
e_ocflags =3D 65792, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D
0xa21e34c8}
lock =3D {off =3D 120264, ndx =3D 605, gen =3D 8677, mode =3D DB_LO=
CK_READ}
num_retries =3D 0
preread_ctrl =3D 0x0
postread_ctrl =3D 0x0
ctrls =3D {0x0, 0x16, 0x9e660068, 0x0, 0x0, 0x0}
num_ctrls =3D 0
rc =3D <value optimized out>
#9 0x080e41f3 in overlay_op_walk (op=3D0xa2d03098, rs=3D0x9fffc0dc,
which=3Dop_modify, oi=3D0x833ca00, on=3D0x0) at backover.c:677
func =3D <value optimized out>
rc =3D <value optimized out>
#10 0x080e4cd9 in over_op_func (op=3D0xa2d03098, rs=3D0x9fffc0dc,
which=3Dop_modify) at backover.c:730
oi =3D <value optimized out>
on =3D 0x834c5f0
be =3D <value optimized out>
db =3D {bd_info =3D 0x81f329c, bd_self =3D 0x833fde0, be_ctrls =3D
"\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\0=
00\001",
'\000' <repeats 12 times>, "\001", be_flags =3D 2312, be_restrictops =3D
0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0,
sss_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0,
sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0,
sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x82b8600,
be_nsuffix =3D 0x833f148, be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0},
be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn =3D
{bv_len =3D 22, bv_val =3D 0x832c598 "cn=3Droot,o=3Dvivates,c=3Dch"}, be_ro=
otndn
=3D {bv_len =3D 22, bv_val =3D 0x833f190 "cn=3Droot,o=3Dvivates,c=3Dch"},
be_rootpw =3D {bv_len =3D 6, bv_val =3D 0x833fd10 "etoile"},
be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600,
lms_t_hard =3D 0, lms_s_soft =3D 500, lms_s_hard =3D 0, lms_s_unchecked =3D
-1, lms_s_pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =
=3D
0x0, be_acl =3D 0x0, be_dfltaccess =3D ACL_READ,
be_extra_anlist =3D 0x0, be_update_ndn =3D {bv_len =3D 0, bv_val =
=3D
0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x82ecff0,
be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __owner =3D 0, _=
_kind
=3D 0, __nusers =3D 0, {__spins =3D 0, __list =3D {__next =3D 0x0}}},
__size =3D '\000' <repeats 23 times>, __align =3D 0},
be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x81f58c0, be_private =3D
0x833fee0, be_next =3D {stqe_next =3D 0x834c268}}
cb =3D {sc_next =3D 0x0, sc_response =3D 0x80e3f10
<over_back_response>, sc_cleanup =3D 0, sc_writewait =3D 0, sc_private =3D
0x833ca00}
sc =3D <value optimized out>
rc =3D 32768
__PRETTY_FUNCTION__ =3D "over_op_func"
#11 0x08091561 in fe_op_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify=
.c:303
update =3D <value optimized out>
repl_user =3D <value optimized out>
op_be =3D <value optimized out>
bd =3D 0x81f8ac0
textbuf =3D
"\000\000\000\000\000\000\000\000\230\000\020\242\342\350\b\b\001\000\000\0=
00\372cM\000n\000\000\000p\355\207\064|\000\000\000[\000\000\000\070\000\00=
0\000\300\273\372\000\270\355,\b\300\355\207\064=C8=AE\377\237?M\t\b\002\00=
0\000\000X\311&\b\200\324'\b\300\355\207\064\300\273\372\000\000\000\000\00=
0\000\000\000\000\030\000\000\000\020\000\020\242\270\273\372\000@\000\020\=
242\300\351\b\b\020\000\020\242\000\000\000\000\250\256\377\237\236=3D?\000=
\020\000\020\242\020\000\000\000`\343\207\064$\346\027\000\000\000\000\000\=
000\000\000\000O\000\000\000`\243\376\002\020\000\000\000\240\373\"\242\000=
\000\000\000\030\210\061\242\000\000\000\000\000\000\000\000(\257\377\237\2=
61\020\t\b\002\000\000\000\030\210\061\242\200\324'\b\300\355\207\064\300\2=
73\372\000\000\000\000\000\374\302\031\b`\262\257\237\020\263\257\237
\273\372\000\030\210\061\242\300\273\372\000'\344\207\064O\000\000\000`\243=
\376\002@\262\257\237"
#12 0x08091fd7 in do_modify (op=3D0xa2d03098, rs=3D0x9fffc0dc) at modify.c:=
177
dn =3D {bv_len =3D 59, bv_val =3D 0x3487e382 "cn=3D1", '0' <repeats=
12
times>, "_O2HP,ou=3DRelationship,dc=3DHPD,o=3Dvivates,c=3Dch"}
textbuf =3D
"\030\000\000\000\070\000\000\000\364\017Q\000\250\277\377\237h\030\060\242=
\030=D5=874\250\277\377\237\004\026\067\000\022\026\067\000\233\275\027\000=
\025\000\000\000#=D5=874\b\000\000\000\374\300\377\237\230\061=D0=A2$\346\0=
27\000x\300\377\237\352\256\027\000P\030\060\242#=D5=874\b\000\000\000P\207=
>\000P\207>\000\340\277\377\237\344\211\031\b\374\300\377\237\230\061=D0=A2=
\000\000\000\000\340\277\377\237\377\000\000\000\001\200\255\373\000\000\00=
0\000\230\061=D0=A2\230\061=D0=A2\230\061=D0=A2\252\061=D0=A2\227\062=D0=A2=
\230\060=D0=A2\240\373\"\242\004\000\020\000\210\300\377\237)\370\f\b\000\0=
00\000\000\240\373\"\242l\300\377\237",
'\000' <repeats 16 times>,
"^V\027\000\000\000\000\000\003\000\000\000\032\000\000\000\000\000\000\000=
=CC=A3\370\267\030\301\377\237\210\300\377\237As\a\b\267\303\066\000\020s\a=
\b\337\v\000\000\274\020\027\000=CC=A3\370\267=CC=A3",
<incomplete sequence \370\267>
tmp =3D <value optimized out>
#13 0x080784ac in connection_operation (ctx=3D0x9fffc1ec,
arg_v=3D0xa2d03098) at connection.c:1158
---Type <return> to continue, or q <return> to quit---
rc =3D 80
cancel =3D <value optimized out>
op =3D 0xa2d03098
rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, sr_er=
r =3D
0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0,
sr_un =3D {sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0,
r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r_v2ref =3D
0x0},
sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =
=3D
0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0}
tag =3D 102
opidx =3D SLAP_OP_MODIFY
conn =3D 0xb7f8a3cc
memctx =3D 0xa222fba0
memctx_null =3D 0x0
memsiz =3D 1048576
__PRETTY_FUNCTION__ =3D "connection_operation"
#14 0x08078d47 in connection_read_thread (ctx=3D0x9fffc1ec, argv=3D0x15)
at connection.c:1294
cri =3D {op =3D 0xa2d03098, func =3D 0, arg =3D 0x0, ctx =3D 0x9fff=
c1ec,
nullop =3D 0}
s =3D 21
#15 0x0013c7d4 in ldap_int_thread_pool_wrapper (xpool=3D0x8287b80) at tpool=
.c:696
pool =3D 0x8287b80
task =3D 0xa2d01fa0
work_list =3D <value optimized out>
ctx =3D {ltu_id =3D 2684341104, ltu_key =3D {{ltk_key =3D 0x8077310=
,
ltk_data =3D 0xa229a680, ltk_free =3D 0x80773e0 <conn_counter_destroy>},
{ltk_key =3D 0x80cf660, ltk_data =3D 0xa222fba0, ltk_free =3D 0x80cf690
<slap_sl_mem_destroy>}, {ltk_key =3D 0x82ed240,
ltk_data =3D 0xa224ba30, ltk_free =3D 0x81336b0
<bdb_reader_free>}, {ltk_key =3D 0x808c910, ltk_data =3D 0xa22661b0,
ltk_free =3D 0x808c720 <slap_op_q_destroy>}, {ltk_key =3D 0x80f6260,
ltk_data =3D 0x9f2fa008, ltk_free =3D 0x80f6320 <search_stack_free>}, {
ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D 0} <repeats 2=
7 times>}}
kctx =3D <value optimized out>
keyslot =3D 697
hash =3D <value optimized out>
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"
#16 0x0036ab39 in start_thread (arg=3D0x9fffcb70) at pthread_create.c:301
__res =3D <value optimized out>
__ignore1 =3D 3039
__ignore2 =3D 6
pd =3D 0x9fffcb70
now =3D <value optimized out>
unwind_buf =3D {cancel_jmp_buf =3D {{jmp_buf =3D {3653620, 0,
4001536, -1610627944, -1207036625, 719275536}, mask_was_saved =3D 0}},
priv =3D {pad =3D {0x0, 0x0, 0x0, 0x0}, data =3D {prev =3D 0x0, cleanup =3D=
0x0,
canceltype =3D 0}}}
not_first_call =3D <value optimized out>
pagesize_m1 =3D <value optimized out>
sp =3D <value optimized out>
freesize =3D <value optimized out>
#17 0x00461c2e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:133
No locals.
--- end gdb ---
If I keep my client application off and I turn it on after I loaded
all the entries in our LDAP, then the synchronization works flawless.
Thanks for the feedback
Maurizio
2015-10-28 17:39 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> --On Wednesday, October 28, 2015 5:23 PM +0000 maurizio.lattuada(a)gmail.co=
m
> wrote:
>
>> --001a1130d27c49538c05232c9dd4
>> Content-Type: text/plain; charset=3DUTF-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=3Dopenldap.git;a=3Dsnapshot;h=
=3Drefs/heads/OPENLDAP_REL_ENG_2_4;sf=3Dtgz>
>
> --Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--=20
Maurizio Lattuada
8 years, 1 month
Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by hyc＠symas.com
ktmdms(a)gmail.com wrote:
> --001a11c39c4eeea62d05232d4fc9
> Content-Type: text/plain; charset=UTF-8
>
> adding the -fstack-protector-all option to the compile of the pw-sha2 on
> the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the
> issue.
Using -fstack-protector-all wasn't intended to fix the issue, it was intended
to make the cause more visible. Instead it has hidden it. Needless to say,
that's not an acceptable resolution for us.
>
> Regards,
>
> Kevin Martin
>
>
>
> ---
>
>
> Regards,
>
> Kevin Martin
>
> On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc(a)symas.com> wrote:
>
>> 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/
>>
>
> --001a11c39c4eeea62d05232d4fc9
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D"ltr">adding the -fstack-protector-all option to the compile of =
> the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to=
> have fixed the issue.<div><br></div><div>Regards,</div><div><br></div><div=
>> Kevin Martin<br><div><br></div><div><br></div></div></div><div class=3D"gm=
> ail_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><sp=
> an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
> e:12.8px">Regards,</span></div><div><div><br></div><div>Kevin Martin</div><=
> /div></div></div></div>
> <br><div class=3D"gmail_quote">On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu =
> <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy=
> c(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
> e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
> lass=3D"">Howard Chu wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> <a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdms(a)gmail.com</a> =
> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> --089e0115ec1091312605232ac99f<br>
> Content-Type: text/plain; charset=3DUTF-8<br>
> <br>
> To add fuel to the fire, if I use pw-sha2 libraries that were built on a<br=
>>
> 2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can<b=
> r>
> generate SHA512/384 hashed passwords with no issues.=C2=A0 What should I be=
> <br>
> looking for between the two platforms that might cause the core?<br>
> </blockquote>
> <br>
> Strange that the kernel would make any difference - more likely it's yo=
> ur C<br>
> compiler making the difference.<br>
> </blockquote>
> <br></span>
> 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.<div class=3D"HOEnZb"><div class=3D"h5"><br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> I ran a test on one machine and got an abort in glibc saying there was a st=
> ack<br>
> overrun. On a different machine I got no such error, and running on the<br>
> problem system under valgrind produced no errors.<br>
> <br>
> On the machine that aborted, when I compiled with gcc -fstack-protector-all=
> ,<br>
> the glibc abort disappeared as well. So, this hasn't helped me identify=
> the<br>
> problem yet. (gcc 4.8.4-2ubuntu1~14.04)<br>
> <br>
> </blockquote>
> <br>
> <br>
> -- <br>
> =C2=A0 -- Howard Chu<br>
> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"=
> http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas=
> .com</a><br>
> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland=
> sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h=
> yc/</a><br>
> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p=
> roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje=
> ct/</a><br>
> </div></div></blockquote></div><br></div>
>
> --001a11c39c4eeea62d05232d4fc9--
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 1 month
Re: (ITS#8294) slappasswd can use SHA256 for hash but not SHA384 or SHA512...segfault
by ktmdms＠gmail.com
--001a11c39c4eeea62d05232d4fc9
Content-Type: text/plain; charset=UTF-8
adding the -fstack-protector-all option to the compile of the pw-sha2 on
the 3.18 machine and recompiling just the pw-sha2 appears to have fixed the
issue.
Regards,
Kevin Martin
---
Regards,
Kevin Martin
On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu <hyc(a)symas.com> wrote:
> 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/
>
--001a11c39c4eeea62d05232d4fc9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">adding the -fstack-protector-all option to the compile of =
the pw-sha2 on the 3.18 machine and recompiling just the pw-sha2 appears to=
have fixed the issue.<div><br></div><div>Regards,</div><div><br></div><div=
>Kevin Martin<br><div><br></div><div><br></div></div></div><div class=3D"gm=
ail_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><sp=
an style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-siz=
e:12.8px">Regards,</span></div><div><div><br></div><div>Kevin Martin</div><=
/div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Oct 28, 2015 at 9:58 AM, Howard Chu =
<span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hy=
c(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">Howard Chu wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<a href=3D"mailto:ktmdms@gmail.com" target=3D"_blank">ktmdms(a)gmail.com</a> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
--089e0115ec1091312605232ac99f<br>
Content-Type: text/plain; charset=3DUTF-8<br>
<br>
To add fuel to the fire, if I use pw-sha2 libraries that were built on a<br=
>
2.6 kernel (specifically 2.6.32-358.el6.x86_64) on the 3.18 machine I can<b=
r>
generate SHA512/384 hashed passwords with no issues.=C2=A0 What should I be=
<br>
looking for between the two platforms that might cause the core?<br>
</blockquote>
<br>
Strange that the kernel would make any difference - more likely it's yo=
ur C<br>
compiler making the difference.<br>
</blockquote>
<br></span>
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.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I ran a test on one machine and got an abort in glibc saying there was a st=
ack<br>
overrun. On a different machine I got no such error, and running on the<br>
problem system under valgrind produced no errors.<br>
<br>
On the machine that aborted, when I compiled with gcc -fstack-protector-all=
,<br>
the glibc abort disappeared as well. So, this hasn't helped me identify=
the<br>
problem yet. (gcc 4.8.4-2ubuntu1~14.04)<br>
<br>
</blockquote>
<br>
<br>
-- <br>
=C2=A0 -- Howard Chu<br>
=C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"=
http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas=
.com</a><br>
=C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland=
sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h=
yc/</a><br>
=C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p=
roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje=
ct/</a><br>
</div></div></blockquote></div><br></div>
--001a11c39c4eeea62d05232d4fc9--
8 years, 1 month
