openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by hyc＠symas.com 04 Nov '15

04 Nov '15

malyn(a)strangeGizmo.com wrote: > Full_Name: Michael Alyn Miller > Version: Git head > OS: Windows 8.1 x64, NixOS 14.12 x64 > URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c > Submission from: (NULL) (96.251.78.237) > > > I have a new repro of an ITS#8264-like situation, but with different input data > and with slightly different results. Note that ITS#8264 was fixed with the > dataset provided in that bug; this is a different dataset and produces different > results. > > The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. > Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the > database. In this case, mdb_del incorrectly removes one extra key (a key > prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place > that should have been deleted (those keys begin with 05000000000000003a...). > This last item is the primary difference between these two bugs. > > Unlike ITS#8264, you do not need to remove the database in between test runs in > order to repro this issue, although the results are still incorrect and will > eventually cause a bus error. Thanks again for the excellent bug reports. Fixed now in git. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8299) LMDB mdb_del data loss when used in a cursor (new repro)
by malyn＠strangeGizmo.com 03 Nov '15

03 Nov '15

Full_Name: Michael Alyn Miller Version: Git head OS: Windows 8.1 x64, NixOS 14.12 x64 URL: ftp://ftp.openldap.org/incoming/michaelalynmiller-151103.c Submission from: (NULL) (96.251.78.237) I have a new repro of an ITS#8264-like situation, but with different input data and with slightly different results. Note that ITS#8264 was fixed with the dataset provided in that bug; this is a different dataset and produces different results. The referenced test runs twice: once with mdb_cursor_del and once with mdb_del. Just like before, mdb_cursor_del performs correctly whereas mdb_del corrupts the database. In this case, mdb_del incorrectly removes one extra key (a key prefixed with 04000000000000003a...), and incorrectly leaves 21 keys in place that should have been deleted (those keys begin with 05000000000000003a...). This last item is the primary difference between these two bugs. Unlike ITS#8264, you do not need to remove the database in between test runs in order to repro this issue, although the results are still incorrect and will eventually cause a bus error.

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 02 Nov '15

02 Nov '15

Hello Quanah, unfortunately I cannot send here the complete and precise schema, is used by our internal proprietary applications. Anyway, it can be described as: * dc=directory ** ou=person ** ou=organization ** ou=relationship "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, clearly other fields like first name, last name, isActive, phone number, address and so on) "ou=organization" has an identifier plus the other "common" fields (name, address...) "ou=relationship" has "objectClass=groupOfNames" and is used to describe: * relationships between persons and organizations ("a person belongs to one or more organization", that is an "organization has these persons as members") * relationships between organizations (e.g. "org_1_a is a sub-organization of the main organization org_1", that is "org_1 has org_1_a as member"). So, considering the schema I described in my previous email: Test-bench_application --> spring_http_invoker --> Server_side_app ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> App_in_syncprov_with_ldap the "Server_side_app" creates in sequence: * one unique organization (let me call it simply "org_p", it has no sub-organization) * about 19500 persons by doing a loop as: ** create one person ** create the related entry in "ou=relationship" to describe "person x belongs to org_p" Meanwhile this procedure is done, the synchronization via syncprov is running to keep in sync the LDAP database 2 and "App_in_syncprov_with_ldap". Hope it helps. thanks for the feedback. 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)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 -- Maurizio Lattuada

1 0

Re: (ITS#8290)
by t-ogura＠az.jp.nec.com 01 Nov '15

01 Nov '15

B server slapd.conf of syncrepl is belw. --- serverID 27 syncrepl rid=3D30 provider=3Dldap://xx.xx.xx.xx bindmethod=3Dsimple binddn=3D"cn=3Dxxxx" credentials=3D"xxxx" searchbase=3D"xxxx" schemachecking=3Doff type=3DrefreshAndPersist retry=3D"2 30 30 +" --- A server slapd.conf of syncrepl is belw. --- serverID 32 syncrepl rid=3D30 provider=3Dldap://xx.xx.xx.xx bindmethod=3Dsimple binddn=3D"cn=3Dxxxx" credentials=3D"xxxx" searchbase=3D"xxxx" schemachecking=3Doff type=3DrefreshAndPersist retry=3D"2 30 30 +" --- Normaly, after update ldap in B server, Master server ldap is updated by sy= ncrepl function. And, A server ldap is updated by syncrepl function. After this issue happend, updating ldap in B server do not replication to M= aster server and A server.

1 0

Re: (ITS#8297) Test061 failed
by michael＠stroeder.com 30 Oct '15

30 Oct '15

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.

1 0

Re: (ITS#8297) Test061 failed
by hyc＠symas.com 30 Oct '15

30 Oct '15

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/

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by quanah＠zimbra.com 30 Oct '15

30 Oct '15

--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

1 0

(ITS#8298) Test061 failed
by a.chelouah＠gmail.com 30 Oct '15

30 Oct '15

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

1 0

(ITS#8297) Test061 failed
by a.chelouah＠gmail.com 30 Oct '15

30 Oct '15

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 30 Oct '15

30 Oct '15

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

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs