- openldap-bugs - openldap.org

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by michael＠stroeder.com 02 Feb '12

02 Feb '12

dcoutadeur(a)linagora.com wrote: > I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git > version) Which exact git version? Did you build RE24 from git already containing the fix for ITS#7113 (dup of ITS#6928)? Ciao, Michael.

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 02 Feb '12

02 Feb '12

--On Thursday, February 02, 2012 4:58 PM +0000 dcoutadeur(a)linagora.com wrote: > Full_Name: dcoutadeur > Version: 2.4.28 > OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (109.197.176.10) > Please rebuild with debugging symbols (CFLAGS=-g) and update with a usable stack trace. Thank you. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by dcoutadeur＠linagora.com 02 Feb '12

02 Feb '12

Full_Name: dcoutadeur Version: 2.4.28 OS: Red Hat Enterprise Linux Server release 5.7 (Tikanga) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.197.176.10) Hi everybody, I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git version) slapd is shutting down with no message in the logs when I try to do a load benchmark with a soft in C. The test consists in 20 threads doing 100 times these operations in the order : - 1 entry add - 1 modification on this entry - 1 deletion on this entry Of course, some operations ends up with ldap errors, because the entry does not exist, and so on... During the load testing, Openldap is reacting as expected. If I stop the test while it runs, then the bug occurs (nearly systematically) You can check my configuration and the stacktrace here. Thank you in advance for helping. # ---------------------------------------------------------------------------- # Global section # ---------------------------------------------------------------------------- sizelimit 15000 allow bind_v2 password-hash {SSHA} threads 8 loglevel 256 serverID 2 include /opt/openldap/etc/openldap/inc_shemas/slapd-schemas.conf pidfile /opt/openldap/var/run/slapd.pid argsfile /opt/openldap/var/run/slapd.args # ACLs definition (cutted here) ####################################################################### # SSL definitions ####################################################################### # Definition of cert files # --------------------------------- TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/certs/ca.cert TLSCertificateFile /usr/local/openldap/etc/certs/ldap-master-2.cert TLSCertificateKeyFile /usr/local/openldap/etc/certs/ldap-master-2.key TLSVerifyClient never ####################################################################### # BDB database definitions ####################################################################### database monitor ####################################################################### # suffix dc=example,dc=com # -------------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "dc=example,dc=com" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 60000 dncachesize 60000 idlcachesize 60000 cachefree 100 rootdn "cn=Manager,dc=example,dc=com" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext # ---------------------------------------------------------------------------- # REPLICATION definitions # ---------------------------------------------------------------------------- ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=001 provider=ldap://ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # limits # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ####################################################################### # suffix o=edition # ---------------- ####################################################################### database bdb directory /opt/openldap/var/openldap-data-edition # some indexes # ---------------------------------------------------------------------------- # root suffix # ---------------------------------------------------------------------------- suffix "o=edition" checkpoint 512 10 # ---------------------------------------------------------------------------- # cache settings # ---------------------------------------------------------------------------- cachesize 50000 dncachesize 50000 idlcachesize 50000 cachefree 100 # ---------------------------------------------------------------------------- # rootdn # ---------------------------------------------------------------------------- # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootdn "cn=Manager,o=edition" rootpw secret # Password policy : hash the clear passwords overlay ppolicy ppolicy_hash_cleartext ####################################################################### # REPLICATION definitions ####################################################################### # I am a master (provider) # ------------------------------------------ overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # syncrepl directive (consummer infos) # ------------------------------------------ syncrepl rid=002 provider=ldap://vspar-ldap-master-1.example.com bindmethod=simple binddn="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" credentials=secret searchbase="o=edition" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on # ---------------------------------------------------------------------------- # Limits for current BDB # ---------------------------------------------------------------------------- limits dn.exact="uid=ReplicationMaster,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationHub,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited limits dn.exact="uid=ReplicationLSC,ou=Replication,ou=Special Users,dc=example,dc=com" size=unlimited time=unlimited ############################################################### ######################## STACKTRACE ########################### ############################################################### (gdb) thread apply all bt Thread 10 (Thread 32314): #0 0x006b3402 in ?? () #1 0x00822a77 in ?? () #2 0xbffb3a5c in ?? () #3 0x00822930 in ?? () #4 0x9c5b2d90 in ?? () #5 0x00000000 in ?? () Thread 9 (Thread 32325): #0 0x006b3402 in ?? () #1 0x00203ae6 in ?? () #2 0x00000000 in ?? () Thread 8 (Thread 32326): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8ccb5258 in ?? () #5 0x8ddb7cd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8ddb7ca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 7 (Thread 32327): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () ---Type <return> to continue, or q <return> to quit--- #3 0x006152a9 in ?? () #4 0x8cbb4258 in ?? () #5 0x8d9b7e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d9b7e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 6 (Thread 32328): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8c9b2258 in ?? () #5 0x8d5b6e68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8d5b6e38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 5 (Thread 32329): #0 0x0019673c in ?? () #1 0x8d1b4fed in ?? () #2 0x089bfbd0 in ?? () #3 0x00000018 in ?? () #4 0x00000009 in ?? () #5 0x081b2684 in ?? () #6 0x0000000a in ?? () #7 0x8d1b4fed in ?? () #8 0x00285ff4 in ?? () #9 0x081b267a in ?? () #10 0x0000000a in ?? () ---Type <return> to continue, or q <return> to quit--- #11 0x8d1b4e98 in ?? () #12 0x0016d391 in ?? () #13 0x8d1b4ebc in ?? () #14 0x081b267a in ?? () #15 0x0000000a in ?? () #16 0x0012eed5 in ?? () #17 0x00000000 in ?? () Thread 4 (Thread 32392): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b6ab258 in ?? () #5 0x8c5afc98 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c5afc68) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 3 (Thread 32393): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b7ac258 in ?? () #5 0x8c1adcd8 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8c1adca8) at syncprov.c:2112 Backtrace stopped: frame did not save the PC ---Type <return> to continue, or q <return> to quit--- Thread 2 (Thread 32394): #0 0x006b3402 in ?? () #1 0x001e790c in ?? () #2 0x006152b7 in ?? () #3 0x006152a9 in ?? () #4 0x8b5aa258 in ?? () #5 0x8bcace68 in ?? () #6 0x0818d941 in syncprov_op_mod (op=0x8240880, rs=0x8bcace38) at syncprov.c:2112 Backtrace stopped: frame did not save the PC Thread 1 (Thread 32391): #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 #7 0x006145e4 in ?? () #8 0x8c9b11e8 in ?? () #9 0x0000002f in ?? () #10 0x00000000 in ?? ()

1 0

(ITS#7149) Back-perl, Back-shell and Binary Data
by jiashun.qian＠atos.net 02 Feb '12

02 Feb '12

Full_Name: Jiashun QIAN Version: 2.4.28 OS: CentOS 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.115.60.180) The backend shell and the backend perl can't handle some binary data. This occurs only with MODIFY because when ADD the binary data is encoded in base64 but not MODIFY. The binary data is truncated when if it contains \0. In fact, data is stored in a linked list of char * and treated as characters. --- servers/slapd/back-perl/modify.c XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); --- The type of mods->sm_values[i].bv_val is char*. To handle the binary data, for back-perl, just change another function mXPUSHp, which we can put the exacte length of mod->sm_values[i].bv_val as parameter, it's mod->sm_values[i].bv_len. So it will push the total data. Same problem in servers/slapd/back-shell/modify.c : --- servers/slapd/back-shell/modify.c fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, mod->sm_values[i].bv_val /* binary! */ ); --- To fix this, uses a loop on mod->sm_values[i].bv_len to get all data. *** openldap-2.4.28.org/servers/slapd/back-perl/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-perl/modify.c 2012-02-02 14:15:37.823838779 +0100 *************** *** 61,67 **** mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! XPUSHs(sv_2mortal(newSVpv( mods->sm_values[i].bv_val, 0 ))); } /* Fix delete attrib without value. */ --- 61,67 ---- mods->sm_values != NULL && mods->sm_values[i].bv_val != NULL; i++ ) { ! mXPUSHp(mods->sm_values[i].bv_val, mods->sm_values[i].bv_len); } /* Fix delete attrib without value. */ *** openldap-2.4.28.org/servers/slapd/back-shell/modify.c 2011-11-25 19:52:29.000000000 +0100 --- openldap-2.4.28/servers/slapd/back-shell/modify.c 2012-02-02 14:26:40.609848244 +0100 *************** *** 49,55 **** Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, --- 49,56 ---- Modifications *ml = op->orm_modlist; Entry e; FILE *rfp, *wfp; ! int i,j; ! unsigned char *ptr; if ( si->si_modify == NULL ) { send_ldap_error( op, rs, LDAP_UNWILLING_TO_PERFORM, *************** *** 105,112 **** if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: %s\n", mod->sm_desc->ad_cname.bv_val, ! mod->sm_values[i].bv_val /* binary! */ ); } } --- 106,118 ---- if( mod->sm_values != NULL ) { for ( i = 0; mod->sm_values[i].bv_val != NULL; i++ ) { ! fprintf( wfp, "%s: ", mod->sm_desc->ad_cname.bv_val ); ! ptr = mod->sm_values[i].bv_val; ! for(j=0; j < mod->sm_values[i].bv_len; j++) ! { ! fprintf( wfp, "%c", *ptr++ ); ! } ! fprintf( wfp, "\n" ); } } Special thanks to : Laurent Le Grandois, Cedric Pellerin, Phillipe Prados for the fix

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 02 Feb '12

02 Feb '12

Sven Hartge wrote: > On 02.02.2012 11:25, Howard Chu wrote: >> Sven Hartge wrote: >>> Um 14:47 Uhr am 01.02.12 schrieb Quanah Gibson-Mount: >>> >>>> Could you *please* try the RE24 checkout from GIT rather than 2.4.28? >>>> Thanks. >>>> That is substantially more useful than patching 2.4.28. >>> >>> I'm sorry to report: still segfaults, backtrace is attached. >> >> This patch should take care of that crash. > > Yes, works. Thank you very much! Thanks for the confirmation, committed to master. -- -- 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#7146) mdb_info.mi_adxs[] overflow
by h.b.furuseth＠usit.uio.no 02 Feb '12

02 Feb '12

Full_Name: Hallvard B Furuseth Version: master: 2e9f1f93c8acf028fffeec3fc8bafd1a19b719b7 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard mdb_info.mi_adxs[] should be a hash table. It is indexed by AttributeDescription.ad_index, which can be > MDB_MAXADS. Currently back-mdb dumps core with 'attributeoptions foo-' in slapd.conf when ldapadding an ldif which does dn: l=e$i,o=adxs objectClass: locality st;foo-$i: bar # optionally: dn: l=e$i,o=adxs changetype: delete for i = 0...66000.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by quanah＠zimbra.com 01 Feb '12

01 Feb '12

--On Wednesday, February 01, 2012 10:27 PM +0000 sven(a)svenhartge.de wrote: > Um 01:00 Uhr am 01.02.12 schrieb Howard Chu: >> Sven Hartge wrote: >>> On 02/01/12 05:56, Howard Chu wrote: >>>> sven(a)svenhartge.de wrote: > >>> > > I get a very good backtrace, but since this backtrace contains >>> > > internal information I am a bit hesitant to attach this backtrace >>> > > to a public bug-report. >>> > >>> > The backtrace you sent shows the crash at a line of code which was >>> > already patched in RE24 due to ITS#7132. I believe this bug is already >>> > fixed. >>> >>> This is good news. Do you have any commit ID so I can try to backport >>> this fix to the version currently in Debian Squeeze? >> >> commit 42faa8393e6cd41a837b526777110b892541773a > > This simple patch applies flawless on 2.4.23 but still segfaults. Will > try on top of 2.4.28 tomorrow, backtraces will follow then, after I > verified my findings. > > > (Reason for trying this on top of 2.4.23 is because this is the version > in Debian Squeeze and I want to provide the DDs with a fix for Squeeze. > I fully understand that is not supported by OpenLDAP.) > Could you *please* try the RE24 checkout from GIT rather than 2.4.28? Thanks. That is substantially more useful than patching 2.4.28. You can check out an tarball of current RE24 with: git archive --format=tar --remote=git.openldap.org:~git/git/openldap.git OPENLDAP_REL_ENG_2_4 > openldap-2.4.29.tar Or via the web with: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

Um 01:00 Uhr am 01.02.12 schrieb Howard Chu: > Sven Hartge wrote: >> On 02/01/12 05:56, Howard Chu wrote: >>> sven(a)svenhartge.de wrote: >> > > I get a very good backtrace, but since this backtrace contains internal >> > > information I am a bit hesitant to attach this backtrace to a public >> > > bug-report. >> > >> > The backtrace you sent shows the crash at a line of code which was >> > already patched in RE24 due to ITS#7132. I believe this bug is already >> > fixed. >> >> This is good news. Do you have any commit ID so I can try to backport >> this fix to the version currently in Debian Squeeze? > > commit 42faa8393e6cd41a837b526777110b892541773a This simple patch applies flawless on 2.4.23 but still segfaults. Will try on top of 2.4.28 tomorrow, backtraces will follow then, after I verified my findings. (Reason for trying this on top of 2.4.23 is because this is the version in Debian Squeeze and I want to provide the DDs with a fix for Squeeze. I fully understand that is not supported by OpenLDAP.) Grüße, Sven.

1 0

(ITS#7145) cn=Connection 0,cn=Connections,cn=Monitor received twice
by michael＠stroeder.com 01 Feb '12

01 Feb '12

Full_Name: Version: RE24 22ee28752e3e0d2a6910a22922fc69befd78578a OS: RHEL 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.34.231) When querying cn=Monitor there are two entries returned with the same DN cn=Connection 0,cn=Connections,cn=Monitor This is a MMR setup with two nodes.

1 0

Re: (ITS#7130) OpenLDAP with BackSQL and Postgres. Upper on bigint?
by dermaniac＠gmail.com 01 Feb '12

01 Feb '12

I'm sorry, I send my issue to the wrong mailinglist at first (to the bugs list) and then tried to send it to technical twice. It doesnt seem to go through. Do you have any idea which column it is that defines this behaviour? I can't seem to find it..

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 01 Feb '12

01 Feb '12

Sven Hartge wrote: > On 02/01/12 05:56, Howard Chu wrote: >> sven(a)svenhartge.de wrote: > >>> I get a very good backtrace, but since this backtrace contains internal >>> information I am a bit hesitant to attach this backtrace to a public >>> bug-report. >> >> The backtrace you sent shows the crash at a line of code which was >> already patched in RE24 due to ITS#7132. I believe this bug is already >> fixed. > > This is good news. Do you have any commit ID so I can try to backport > this fix to the version currently in Debian Squeeze? commit 42faa8393e6cd41a837b526777110b892541773a -- -- 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#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 01 Feb '12

01 Feb '12

On 02/01/12 05:56, Howard Chu wrote: > sven(a)svenhartge.de wrote: >> I get a very good backtrace, but since this backtrace contains internal >> information I am a bit hesitant to attach this backtrace to a public >> bug-report. > > The backtrace you sent shows the crash at a line of code which was > already patched in RE24 due to ITS#7132. I believe this bug is already > fixed. This is good news. Do you have any commit ID so I can try to backport this fix to the version currently in Debian Squeeze? Grüße, Sven.

1 0

Re: (ITS#7144) reproducible segfault on slave/consumer during sync-replication
by hyc＠symas.com 01 Feb '12

01 Feb '12

sven(a)svenhartge.de wrote: > Full_Name: Sven Hartge > Version: 2.4.28 > OS: Debian Squeeze > URL: > Submission from: (NULL) (2a01:198:329:1::14) > > > I experience an easy to reproduce and consistent segfault when I setup a slapd > > syncrepl consumer on Squeeze. > > > > This segfault always happens during the replication of the same object, but the > > slapd version in Lenny has no problems with same DIT. > I get a very good backtrace, but since this backtrace contains internal > > information I am a bit hesitant to attach this backtrace to a public bug-report. The backtrace you sent shows the crash at a line of code which was already patched in RE24 due to ITS#7132. I believe this bug is already fixed. > Is there a way to privatly submit this data (backtrace and additional schemas) > > so you can have look at the problem? -- -- 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#7144) reproducible segfault on slave/consumer during sync-replication
by sven＠svenhartge.de 31 Jan '12

31 Jan '12

Full_Name: Sven Hartge Version: 2.4.28 OS: Debian Squeeze URL: Submission from: (NULL) (2a01:198:329:1::14) I experience an easy to reproduce and consistent segfault when I setup a slapd syncrepl consumer on Squeeze. This segfault always happens during the replication of the same object, but the slapd version in Lenny has no problems with same DIT. My oldstable replicas currently run a self-backported version of 2.4.21-1~dvz50+1, but both 2.4.17-2.1~bpo50+1 and 2.4.11-1+lenny2.1 are also fine. 2.4.23-7.2 shows the segfault as all versions up to 2.4.28-1.1 do. Even if I disable all indices and strip my configuration to the bare minimum needed (i.e. self-defined objectclasses and attributes) I get the segfault. I also did da -O0 rebuild of the Debian-2.4.28 and this also segfaults in the same way as 2.4.23 did. I have yet to test the latest RelEng24 from GIT, but I wanted to submit this issue so someone may have a look at the backtrace in parallel to my further tests. I am aware the problem my lie in my self-defined objectclasses and attributes, but then slapd should throw an error and exit instead of replicating 1/3 of the DIT and then segfault. I get a very good backtrace, but since this backtrace contains internal information I am a bit hesitant to attach this backtrace to a public bug-report. Is there a way to privatly submit this data (backtrace and additional schemas) so you can have look at the problem?

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. Are you building the latest source? You can use --with-tls=openssl (or gnutls) to explicitly choose. But it shouldn't be defaulting to MozNSS, unless perhaps you're on a Redhat or Fedora system. If worse comes to worse, you can configure --without-tls just to run this test. -- -- 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#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 31 Jan '12

31 Jan '12

On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > Mattias Andersson wrote: >> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >> >>> Please provide a full gdb backtrace from the assertion failure. I've >>> reproduced this configuration locally but see no crash using >>> ldapsearch. >>> I don't have the Softerra browser. >> >> Ok, see attachment. The problem is not reproducible with ldapsearch. > > Please see if the attached patch alters the behavior. Thanks. I'm getting an error that MozNSS is not found when I run ./configure. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

This is a multi-part message in MIME format. --------------090902020105000306040907 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> mattias(a)centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. Please see if the attached patch alters the behavior. Thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------090902020105000306040907 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/overlays/rwm.c b/servers/slapd/overlays/rwm.c index 05cf98a..37e52cb 100644 --- a/servers/slapd/overlays/rwm.c +++ b/servers/slapd/overlays/rwm.c @@ -1277,7 +1277,7 @@ rwm_attrs( Operation *op, SlapReply *rs, Attribute** a_first, int stripEntryDN ) NULL ); if ( rc != LDAP_SUCCESS ) { - BER_BVZERO( &(*ap)->a_nvals[i] ); + ber_dupbv( &(*ap)->a_nvals[i], &(*ap)->a_vals[i] ); } } BER_BVZERO( &(*ap)->a_nvals[i] ); --------------090902020105000306040907--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

Mattias Andersson wrote: > On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: > >> mattias(a)centaurix.com wrote: >>> Full_Name: Mattias Andersson >>> Version: 2.4.25 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.182.107.220) >> >> Please provide a full gdb backtrace from the assertion failure. I've >> reproduced this configuration locally but see no crash using ldapsearch. >> I don't have the Softerra browser. > > Ok, see attachment. The problem is not reproducible with ldapsearch. The assertion leads me to believe that one of the values received from the remote server violated the attribute syntax, and so the value failed in the normalizer on the local slapd. What is the remote server? It's a bit strange that changing the configuration, but leaving the remote server unchanged, avoids the problem. > In any case, I have a different configuration now, that solves the problem > in another way (by using two separate local databases -- one for the > translucent overlay and one for the subordinate directory.) Another > problem with the previous configuration was that I was getting "user > modification of overlay database not permitted" errors when using > ldapadd/ldapmodify (seems the translucent overlay can not be stacked with > the rwm overlay.) > > Mattias -- -- 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#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 31 Jan '12

31 Jan '12

------------hvfQvbIMuXxQGZ2Ols8tGf Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu <hyc(a)symas.com> wrote: > mattias(a)centaurix.com wrote: >> Full_Name: Mattias Andersson >> Version: 2.4.25 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.182.107.220) > > Please provide a full gdb backtrace from the assertion failure. I've > reproduced this configuration locally but see no crash using ldapsearch. > I don't have the Softerra browser. Ok, see attachment. The problem is not reproducible with ldapsearch. >> This is a security vulnerability, since it would be enough to send an >> LDAP query >> to take down the server. > > We don't consider crashes/DOS to be a security vulnerability. A > vulnerability is anything which allows users to see information they > should not be allowed to see; in the case of a crash no information can > be retrieved so all data is completely secure. You're right, but it's a service vulnerability -- the server must be online in order for our users to be able to log in. In any case, I have a different configuration now, that solves the problem in another way (by using two separate local databases -- one for the translucent overlay and one for the subordinate directory.) Another problem with the previous configuration was that I was getting "user modification of overlay database not permitted" errors when using ldapadd/ldapmodify (seems the translucent overlay can not be stacked with the rwm overlay.) Mattias ------------hvfQvbIMuXxQGZ2Ols8tGf Content-Disposition: attachment; filename=gdb-slapd.txt Content-Type: text/plain; name="gdb-slapd.txt" Content-Transfer-Encoding: Quoted-Printable GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.= html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copyin= g" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. (gdb) handle SIG33 pass nostop noprint Signal Stop Print Pass to program Description SIG33 No No Yes Real-time event 33 (gdb) set pagination 0 (gdb) attach 4625 Attaching to process 4625 ptrace: No such process. (gdb) attach 4824 Attaching to process 4824 ptrace: No such process. (gdb) attach 4864 Attaching to process 4864 Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/deb= ug/usr/sbin/slapd...done. done. Reading symbols from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2...(no = debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 Reading symbols from /usr/lib/libslp.so.1...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib/libslp.so.1 Reading symbols from /usr/lib/x86_64-linux-gnu/libsasl2.so.2...(no debug= ging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libsasl2.so.2 Reading symbols from /lib/x86_64-linux-gnu/libcrypt.so.1...(no debugging= symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcrypt.so.1 Reading symbols from /usr/lib/libltdl.so.7...(no debugging symbols found= )...done. Loaded symbols for /usr/lib/libltdl.so.7 Reading symbols from /lib/x86_64-linux-gnu/libwrap.so.0...(no debugging = symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libwrap.so.0 Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debuggi= ng symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0x7f66e2c7d700 (LWP 4865)] Loaded symbols for /lib/x86_64-linux-gnu/libpthread.so.0 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging sym= bols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6 Reading symbols from /lib/x86_64-linux-gnu/libresolv.so.2...(no debuggin= g symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libresolv.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libgnutls.so.26...(no deb= ugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libgnutls.so.26 Reading symbols from /lib/x86_64-linux-gnu/libgcrypt.so.11...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgcrypt.so.11 Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging s= ymbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1 Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging sy= mbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols= found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libkrb5.so.3...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5.so.3 Reading symbols from /usr/lib/x86_64-linux-gnu/libk5crypto.so.3...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 Reading symbols from /lib/x86_64-linux-gnu/libcom_err.so.2...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcom_err.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libkrb5support.so.0...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 Reading symbols from /usr/lib/x86_64-linux-gnu/libtasn1.so.3...(no debug= ging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libtasn1.so.3 Reading symbols from /lib/x86_64-linux-gnu/libz.so.1...(no debugging sym= bols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libz.so.1 Reading symbols from /lib/x86_64-linux-gnu/libgpg-error.so.0...(no debug= ging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libgpg-error.so.0 Reading symbols from /lib/x86_64-linux-gnu/libkeyutils.so.1...(no debugg= ing symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libkeyutils.so.1 Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debug= ging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2 Reading symbols from /lib/libnss_mdns4_minimal.so.2...(no debugging symb= ols found)...done. Loaded symbols for /lib/libnss_mdns4_minimal.so.2 Reading symbols from /lib/x86_64-linux-gnu/libnss_dns.so.2...(no debuggi= ng symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libnss_dns.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so...(no d= ebugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so...(= no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so...(= no debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so Reading symbols from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0...(no debu= gging symbols found)...done. Loaded symbols for /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so...(no= debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so...(no de= bugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so...(no = debugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-5.1.so...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-5.1.so Reading symbols from /usr/lib/x86_64-linux-gnu/sasl2/libplain.so...(no d= ebugging symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/sasl2/libplain.so Reading symbols from /usr/lib/ldap/back_hdb-2.4.so.2...Reading symbols f= rom /usr/lib/debug/usr/lib/ldap/back_hdb-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_hdb-2.4.so.2 Reading symbols from /usr/lib/x86_64-linux-gnu/libdb-4.8.so...(no debugg= ing symbols found)...done. Loaded symbols for /usr/lib/x86_64-linux-gnu/libdb-4.8.so Reading symbols from /usr/lib/ldap/back_ldap-2.4.so.2...Reading symbols = from /usr/lib/debug/usr/lib/ldap/back_ldap-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_ldap-2.4.so.2 Reading symbols from /usr/lib/ldap/back_relay-2.4.so.2...Reading symbols= from /usr/lib/debug/usr/lib/ldap/back_relay-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/back_relay-2.4.so.2 Reading symbols from /usr/lib/ldap/translucent-2.4.so.2...Reading symbol= s from /usr/lib/debug/usr/lib/ldap/translucent-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/translucent-2.4.so.2 Reading symbols from /usr/lib/ldap/rwm-2.4.so.2...Reading symbols from /= usr/lib/debug/usr/lib/ldap/rwm-2.4.so.2.7.0...done. done. Loaded symbols for /usr/lib/ldap/rwm-2.4.so.2 0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/libpthr= ead.so.0 (gdb) continue Continuing. [New Thread 0x7f66e247c700 (LWP 4874)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7f66e247c700 (LWP 4874)] 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) backtrace full #0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li= bc.so.6 No symbol table info available. #3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a= 40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236 i =3D <optimized out> j =3D <optimized out> __PRETTY_FUNCTION__ =3D "attr_dup2" #4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build= d/openldap-2.4.25/servers/slapd/attr.c:279 i =3D <optimized out> tmp =3D 0x7f66e9a40db8 anew =3D 0x7f66e9a40e08 #5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x= 7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989= __PRETTY_FUNCTION__ =3D "entry_dup2" #6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f= 66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.= c:1493 on =3D 0x7f66e99b43c0 rwmap =3D <optimized out> e =3D 0x7f66e9a2cee8 dn =3D {bv_len =3D 0, bv_val =3D 0x0} ndn =3D {bv_len =3D 0, bv_val =3D 0x0} dc =3D {rwmap =3D 0x7f66e99b45a0, conn =3D 0x7f66e91dde50, ctx =3D= 0x7f66e33e5ec3 "searchEntryDN", rs =3D 0x0} rc =3D <optimized out> __PRETTY_FUNCTION__ =3D "rwm_send_entry" #7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:= 1735 on =3D <optimized out> rwmap =3D <optimized out> rc =3D <optimized out> #8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.= c:237 oi =3D <optimized out> on =3D 0x7f66e99b43c0 rc =3D 32768 be =3D 0x7f66e99b7340 db =3D {bd_info =3D 0x7f66e99b43c0, bd_self =3D 0x7f66e99b7340, = be_ctrls =3D "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times= >, "\001", be_flags =3D 257, 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_sas= l =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tl= s =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}, be_suffix =3D 0x= 7f66e99b4180, be_nsuffix =3D 0x7f66e99b41b0, 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 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0= , bv_val =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_= deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D 100, 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_update_ndn =3D {bv_len =3D= 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7= f66e99d2850, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, = __owner =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {= __prev =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, = __align =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66= e3c160a0, be_private =3D 0x7f66e99b7500, be_next =3D {stqe_next =3D 0x0}= } #9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:= 505 sc_next =3D 0x0 sc_nextp =3D 0x7f66e247a690 rc =3D 32768 sc =3D 0x7f66e247a5e0 scp =3D 0x7f66e247a5e0 #10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r= s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul= t.c:997 berbuf =3D {buffer =3D "\230\244G\342f\177\000\000\222M\303\350f= \177\000\000x\n\244\351f\177\000\000 ", '\000' <repeats 15 times>, "\n\0= 23\000\000\000\000\000\000 `\260\351f\177\000\000\020\000\000\000f\177\0= 00\000\240\243G\342f\177\000\000\060\243G\342f\177\000\000d\001\000\000\= 000\000\000\000n\374\300\351f\177\000\000 \247c\351f\177\000\000{\001\00= 0\000\000\000\000\000=C8=A3G\342f\177\000\000\220\n\244\351f\177\000\000= \000\000\000\000\000\000\000\000P\374\300\351f\177\000\000S\374\300\351f= \177\000\000\000\000\000\000\000\000\000\000P\374\300\351f\177\000\000\2= 60]\260\351f\177\000\000\260]\260\351f\177\000\000p\271G\342f\177\000\00= 0\367\377\377\377\000\000\000\000\000u\233\351f\177\000\000\000\000\000\= 000\000\000\000\000\342/\346\350f\177\000\000\002\000\001\000\000\001\00= 0\000\000\000\000\000\000\000\000\000\202\001", '\000' <repeats 13 times= >, ialign =3D -498621288, lalign =3D 140079859737752, falign =3D -9.2069= 0575e+20, dalign =3D 6.9208646370683671e-310, palign =3D 0x7f66e247a498 = "\021"} ber =3D 0x7f66e247a2c0 a =3D <optimized out> i =3D <optimized out> j =3D <optimized out> rc =3D 0 bytes =3D <optimized out> userattrs =3D <optimized out> acl_state =3D {as_desc =3D 0x0, as_access =3D ACL_NONE, as_vd_ac= l =3D 0x0, as_vd_acl_present =3D 0, as_vd_acl_count =3D 0, as_vd_mask =3D= 1, as_result =3D -1, as_fe_done =3D 0} attrsonly =3D <optimized out> ad_entry =3D 0x7f66e995acc0 e_flags =3D 0x0 #11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o= ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/= search.c:335 ent =3D {e_id =3D 0, e_name =3D {bv_len =3D 17, bv_val =3D 0x7f6= 6e9b068f8 "dc=3Dchalmers,dc=3Dse"}, e_nname =3D {bv_len =3D 17, bv_val =3D= 0x7f66e9b06958 "dc=3Dchalmers,dc=3Dse"}, e_attrs =3D 0x7f66e9a407c8, e_= ocflags =3D 0, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x= 0} bdn =3D {bv_len =3D 17, bv_val =3D 0x7f66e9c0fc59 "dc=3Dchalmers= ,dc=3Dse"} li =3D <optimized out> lc =3D 0x7f66e9c06400 tv =3D {tv_sec =3D 0, tv_usec =3D 100000} stoptime =3D 1327979004 res =3D 0x7f66e9c0fa80 e =3D <optimized out> rc =3D 0 msgid =3D 2 match =3D {bv_len =3D 0, bv_val =3D 0x0} filter =3D {bv_len =3D 15, bv_val =3D 0x7f66e9b06680 "(objectCla= ss=3D*)"} i =3D <optimized out> attrs =3D <optimized out> freetext =3D 0 filter_undef =3D 0 do_retry =3D 0 dont_retry =3D 1 ctrls =3D 0x0 references =3D 0x0 __PRETTY_FUNCTION__ =3D "ldap_back_search" #12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/= translucent.c:1111 on =3D 0x7f66e99b7160 ov =3D 0x7f66e99b7340 cb =3D {sc_next =3D 0x7f66e247a690, sc_response =3D 0x7f66e35ebc= d0 <translucent_search_cb>, sc_cleanup =3D 0, sc_private =3D 0x7f66e247a= 5b0} tc =3D {db =3D 0x7f66e247a6b0, on =3D 0x7f66e99b7160, orig =3D 0= x7f66e9b06658, list =3D 0x0, step =3D 0, slimit =3D 100, attrs =3D 0x7f6= 6e9b066a0} fl =3D 0x0 fr =3D 0x0 fbv =3D <optimized out> rc =3D 0 #13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7= f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160= ) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659 func =3D 0x7f66e99b71b8 rc =3D 32768 #14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim= ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser= vers/slapd/backover.c:721 oi =3D <optimized out> on =3D <optimized out> be =3D 0x7f66e99b3f70 db =3D {bd_info =3D 0x7f66e99b7160, bd_self =3D 0x7f66e99b3f70, = be_ctrls =3D "\000", '\001' <repeats 15 times>, '\000' <repeats 16 times= >, be_flags =3D 275, 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 0x7f66e99b= 4180, be_nsuffix =3D 0x7f66e99b41b0, be_schemadn =3D {bv_len =3D 0, bv_v= al =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootdn = =3D {bv_len =3D 0, bv_val =3D 0x0}, be_rootndn =3D {bv_len =3D 0, bv_val= =3D 0x0}, be_rootpw =3D {bv_len =3D 0, bv_val =3D 0x0}, be_max_deref_de= pth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms= _s_soft =3D 100, 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_update_ndn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x7f66e9= 9d27c0, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D 0, __own= er =3D 0, __nusers =3D 0, __kind =3D 0, __spins =3D 0, __list =3D {__pre= v =3D 0x0, __next =3D 0x0}}, __size =3D '\000' <repeats 39 times>, __ali= gn =3D 0}, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_cf_ocs =3D 0x7f66e39f3= 020, be_private =3D 0x7f66e99b4100, be_next =3D {stqe_next =3D 0x0}} cb =3D {sc_next =3D 0x0, sc_response =3D 0x7f66e935aa50 <over_ba= ck_response>, sc_cleanup =3D 0, sc_private =3D 0x7f66e99b41e0} sc =3D <optimized out> rc =3D 32768 __PRETTY_FUNCTION__ =3D "over_op_func" #15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372 bd =3D 0x7f66e95f9a80 #16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24= 7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217 base =3D {bv_len =3D 17, bv_val =3D 0x7f66e9b05f9b "dc=3Dchalmer= s,dc=3Dse"} siz =3D 1 off =3D 0 i =3D <optimized out> #17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar= g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con= nection.c:1113 rc =3D 80 cancel =3D <optimized out> op =3D 0x7f66e9b06020 rs =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr= _err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrl= s =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x7f66e9a2cee8, r_attr= _flags =3D 17, r_operational_attrs =3D 0x7f66e9a40ac0, r_attrs =3D 0x7f6= 6e9b066a0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata = =3D 0x7f66e9a2cee8}, sru_extended =3D {r_rspoid =3D 0x7f66e9a2cee8 "", r= _rspdata =3D 0x11}}, sr_flags =3D 2} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D 0x7f66e91dde50 memctx =3D 0x7f66e9b05f50 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, = argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c= onnection.c:1249 rc =3D <optimized out> cri =3D {op =3D 0x7f66e9b06020, func =3D 0, arg =3D 0x0, ctx =3D= 0x7f66e247bb60, nullop =3D <optimized out>} s =3D <optimized out> #19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r= -2.4.so.2 No symbol table info available. #20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 No symbol table info available. #21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #22 0x0000000000000000 in ?? () No symbol table info available. (gdb) info registers rax 0x0 0 rbx 0x7fff061cce37 140733295939127 rcx 0xffffffffffffffff -1 rdx 0x6 6 rsi 0x130a 4874 rdi 0x1300 4864 rbp 0x7f66e7d591da 0x7f66e7d591da rsp 0x7f66e2479d28 0x7f66e2479d28 r8 0x7f66e247c700 140079859746560 r9 0x3c206a60206e6f69 4332579802623930217 r10 0x8 8 r11 0x206 518 r12 0xec 236 r13 0x7f66e9394c94 140079976238228 r14 0x7f66e9394ca1 140079976238241 r15 0x7f66e7d591da 140079952925146 rip 0x7f66e7c343a5 0x7f66e7c343a5 <raise+53> eflags 0x206 [ PF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) x/16i $pc =3D> 0x7f66e7c343a5 <raise+53>: cmp $0xfffffffffffff000,%rax 0x7f66e7c343ab <raise+59>: ja 0x7f66e7c343bf <raise+79> 0x7f66e7c343ad <raise+61>: repz retq = 0x7f66e7c343af <raise+63>: nop 0x7f66e7c343b0 <raise+64>: test %eax,%eax 0x7f66e7c343b2 <raise+66>: jg 0x7f66e7c34395 <raise+37> 0x7f66e7c343b4 <raise+68>: test $0x7fffffff,%eax 0x7f66e7c343b9 <raise+73>: je 0x7f66e7c343d0 <raise+96> 0x7f66e7c343bb <raise+75>: neg %eax 0x7f66e7c343bd <raise+77>: jmp 0x7f66e7c34395 <raise+37> 0x7f66e7c343bf <raise+79>: mov 0x361a52(%rip),%rdx # 0x7f66= e7f95e18 0x7f66e7c343c6 <raise+86>: neg %eax 0x7f66e7c343c8 <raise+88>: mov %eax,%fs:(%rdx) 0x7f66e7c343cb <raise+91>: or $0xffffffffffffffff,%rax 0x7f66e7c343cf <raise+95>: retq = 0x7f66e7c343d0 <raise+96>: mov %esi,%eax (gdb) thread apply all backtrace Thread 3 (Thread 0x7f66e247c700 (LWP 4874)): #0 0x00007f66e7c343a5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f66e7c37b0b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f66e7c2cd4d in __assert_fail () from /lib/x86_64-linux-gnu/li= bc.so.6 #3 0x00007f66e92f8293 in attr_dup2 (tmp=3D0x7f66e9a40db8, a=3D0x7f66e9a= 40e80) at /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236 #4 0x00007f66e92f86a2 in attrs_dup (a=3D0x7f66e9a40e80) at /build/build= d/openldap-2.4.25/servers/slapd/attr.c:279 #5 0x00007f66e92fb83a in entry_dup2 (dest=3D0x7f66e9a2ce98, source=3D0x= 7f66e9a2cee8) at /build/buildd/openldap-2.4.25/servers/slapd/entry.c:989= #6 0x00007f66e33e147e in rwm_send_entry (op=3D0x7f66e9b06020, rs=3D0x7f= 66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.= c:1493 #7 0x00007f66e33e1702 in rwm_response (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/rwm.c:= 1735 #8 0x00007f66e935aac8 in over_back_response (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/backover.= c:237 #9 0x00007f66e92ff267 in slap_response_play (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/result.c:= 505 #10 0x00007f66e9301d6d in slap_send_search_entry (op=3D0x7f66e9b06020, r= s=3D0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/resul= t.c:997 #11 0x00007f66e3a00939 in ldap_back_search (op=3D0x7f66e9b06020, rs=3D<o= ptimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/back-ldap/= search.c:335 #12 0x00007f66e35ebca7 in translucent_search (op=3D0x7f66e9b06020, rs=3D= 0x7f66e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/overlays/= translucent.c:1111 #13 0x00007f66e935b5aa in overlay_op_walk (op=3D0x7f66e9b06020, rs=3D0x7= f66e247b940, which=3Dop_search, oi=3D0x7f66e99b41e0, on=3D0x7f66e99b7160= ) at /build/buildd/openldap-2.4.25/servers/slapd/backover.c:659 #14 0x00007f66e935b76b in over_op_func (op=3D0x7f66e9b06020, rs=3D<optim= ized out>, which=3D<optimized out>) at /build/buildd/openldap-2.4.25/ser= vers/slapd/backover.c:721 #15 0x00007f66e92f2559 in fe_op_search (op=3D0x7f66e9b06020, rs=3D0x7f66= e247b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:372 #16 0x00007f66e92f1e36 in do_search (op=3D0x7f66e9b06020, rs=3D0x7f66e24= 7b940) at /build/buildd/openldap-2.4.25/servers/slapd/search.c:217 #17 0x00007f66e92ef6b7 in connection_operation (ctx=3D0x7f66e247bb60, ar= g_v=3D0x7f66e9b06020) at /build/buildd/openldap-2.4.25/servers/slapd/con= nection.c:1113 #18 0x00007f66e92ef9de in connection_read_thread (ctx=3D0x7f66e247bb60, = argv=3D<optimized out>) at /build/buildd/openldap-2.4.25/servers/slapd/c= onnection.c:1249 #19 0x00007f66e8e4e85a in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r= -2.4.so.2 #20 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #21 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #22 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f66e2c7d700 (LWP 4865)): #0 0x00007f66e7cdfef3 in epoll_wait () from /lib/x86_64-linux-gnu/libc.= so.6 #1 0x00007f66e92ea440 in slapd_daemon_task (ptr=3D<optimized out>) at /= build/buildd/openldap-2.4.25/servers/slapd/daemon.c:2528 #2 0x00007f66e7fa4efc in start_thread () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #3 0x00007f66e7cdf89d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f66e928d740 (LWP 4864)): #0 0x00007f66e7fa61f8 in pthread_join () from /lib/x86_64-linux-gnu/lib= pthread.so.0 #1 0x00007f66e92ec9a2 in slapd_daemon () at /build/buildd/openldap-2.4.= 25/servers/slapd/daemon.c:2922 #2 0x00007f66e92d4013 in main (argc=3D3, argv=3D<optimized out>) at /bu= ild/buildd/openldap-2.4.25/servers/slapd/main.c:1008 (gdb) quit A debugging session is active. Inferior 1 [process 4864] will be detached. Quit anyway? (y or n) Quitting: Can't detach Thread 0x7f66e2c7d700 (LWP = 4865): No such process ------------hvfQvbIMuXxQGZ2Ols8tGf--

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by hyc＠symas.com 31 Jan '12

31 Jan '12

mattias(a)centaurix.com wrote: > Full_Name: Mattias Andersson > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.182.107.220) Please provide a full gdb backtrace from the assertion failure. I've reproduced this configuration locally but see no crash using ldapsearch. I don't have the Softerra browser. > I have configured a proxy server using both the relay backend and the > translucent overlay: > > backend hdb > backend relay > > database hdb > directory /var/lib/ldap > suffix "dc=foo,dc=example,dc=com" > rootdn "cn=admin,dc=foo,dc=example,dc=com" > rootpw secret > index objectClass eq > > database relay > suffix "dc=example,dc=com" > overlay rwm > rwm-suffixmassage "dc=foo,dc=example,dc=com" > overlay translucent > uri ldap://ldap.example.com > > This configuration makes it possible for me to override attributes in the remote > ldap directory and at the same time extend the local directory with new entries. > This has been tested and works for authorization in a linux environment. > > If I issue an LDAP search query, as follows, > > ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 > > it will yield the following debug output: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=1000 op=2 UNBIND > conn=1000 fd=11 closed > > However, if I query the server using the Softerra LDAP Administrator software > (Windows), the slapd daemon crashes with an assertion error: > > slapd starting > conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) > conn=1000 op=0 BIND dn="" method=128 > conn=1000 op=0 RESULT tag=97 err=0 text= > conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 > filter="(objectClass=*)" > conn=1000 op=1 SRCH attr=1.1 > conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. > slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: > Assertion `j< i' failed. > Aborted > > This is a security vulnerability, since it would be enough to send an LDAP query > to take down the server. We don't consider crashes/DOS to be a security vulnerability. A vulnerability is anything which allows users to see information they should not be allowed to see; in the case of a crash no information can be retrieved so all data is completely secure. -- -- 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#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 29 Jan '12

29 Jan '12

Full_Name: Mattias Andersson Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.182.107.220) I have configured a proxy server using both the relay backend and the translucent overlay: backend hdb backend relay database hdb directory /var/lib/ldap suffix "dc=foo,dc=example,dc=com" rootdn "cn=admin,dc=foo,dc=example,dc=com" rootpw secret index objectClass eq database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=foo,dc=example,dc=com" overlay translucent uri ldap://ldap.example.com This configuration makes it possible for me to override attributes in the remote ldap directory and at the same time extend the local directory with new entries. This has been tested and works for authorization in a linux environment. If I issue an LDAP search query, as follows, ldapsearch -x -b dc=chalmers,dc=se -s base "(objectClass=*)" 1.1 it will yield the following debug output: slapd starting conn=1000 fd=11 ACCEPT from IP=127.0.0.1:36838 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1000 op=2 UNBIND conn=1000 fd=11 closed However, if I query the server using the Softerra LDAP Administrator software (Windows), the slapd daemon crashes with an assertion error: slapd starting conn=1000 fd=11 ACCEPT from IP=11.22.33.44:54752 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="" method=128 conn=1000 op=0 RESULT tag=97 err=0 text= conn=1000 op=1 SRCH base="dc=example,dc=com" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=1.1 conn=1000 op=1: back-relay for DN="dc=example,dc=com" would call self. slapd: /build/buildd/openldap-2.4.25/servers/slapd/attr.c:236: attr_dup2: Assertion `j < i' failed. Aborted This is a security vulnerability, since it would be enough to send an LDAP query to take down the server. Mattias

1 0

(ITS#7142) slapadd with tool-threads hangs on failure
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

Full_Name: Hallvard B Furuseth Version: 2.4.28, master OS: Linux x86_64 URL: http://folk.uio.no/hbf/toobig.sh Submission from: (NULL) (195.1.106.125) Submitted by: hallvard slapadd hangs if bi_tool_entry_put() fails. Tested with back-ldif patched for bi_tool_entry_put() to return NOID after 6 entries, and on master with mdb and an LDIF > DB maxsize. Test program enclosed. Backtrace: Thread 2 (Thread 0x7fb3745fd700 (LWP 31479)): #0 0x000000371fc0b3dc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x000000000048acaf in getrec_thr (ctx=<value optimized out>) at slapadd.c:296 #2 0x000000371fc077f1 in start_thread () from /lib64/libpthread.so.0 Thread 1 (Thread 0x7fb37542e7c0 (LWP 31478)): #0 0x000000371fc0804d in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000048a8e5 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:454 #2 0x0000000000406ea5 in main (argc=5, argv=<value optimized out>) at main.c:655 I don't want to touch that code, don't remember why nearby code uses ldap_pvt_tread_yield() instead of the clean way of having two conds (one for producer and one for consumer to wait for).

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by h.b.furuseth＠usit.uio.no 28 Jan '12

28 Jan '12

On Sat, 28 Jan 2012 16:52:05 GMT, michael(a)stroeder.com wrote: > Hmm, it seems I get better result linking smbk5pwd with > contrib/slapd-modules/smbk5pwd/Makefile containing: > > LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs > -L../../../libraries/liblber/.libs > > instead of just > > LDAP_LIB=-lldap_r -llber > > Is that the right solution when rpath is already set when invoking > configure? If you build *and install* the rest of OpenLDAP first and then build smbk5pwd, I imagine it'll work fine if -L and -rpath are the same. Otherwise you should point -L at where all the libraries-to-be-installed are, which with a dynamic build is the .lib/ directories. After all -L is for build time and -rpath for runtime, and they should be set so that you build against the same libraries you will run with. At least I hope that's all. I wouldn't be surprised if some libtool magic introduces more complications:-( -- Hallvard

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

michael(a)stroeder.com wrote: > Uumpf! I forgot to update my local version of > > contrib/slapd-modules/smbk5pwd/Makefile > > after pulling from git. This Makefile does not use prefix and LDFLAGS used > with ./configure before. Hmm, it seems I get better result linking smbk5pwd with contrib/slapd-modules/smbk5pwd/Makefile containing: LDAP_LIB=-lldap_r -llber -L../../../libraries/libldap_r/.libs -L../../../libraries/liblber/.libs instead of just LDAP_LIB=-lldap_r -llber Is that the right solution when rpath is already set when invoking configure? Ciao, Michael.

1 0

Re: (ITS#7141) Segmentation fault during stopping slapd
by michael＠stroeder.com 28 Jan '12

28 Jan '12

Hallvard B Furuseth wrote: > On Sat, 28 Jan 2012 15:10:24 GMT, michael(a)stroeder.com wrote: >> Core was generated by `/opt/openldap-RE24/libexec/slapd (...) >> (...) >> #1 0x00007fc67d5329a3 in ?? () from /usr/lib64/libldap_r-2.4.so.2 > > Looks like slapd is linked to the wrong libldap_r, and you need > to configure with something like > > $ pr=/opt/openldap-RE24 > $ ./configure --prefix=$pr LDFLAGS="-L$pr/lib -Wl,-rpath,$pr/lib" Uumpf! I forgot to update my local version of contrib/slapd-modules/smbk5pwd/Makefile after pulling from git. This Makefile does not use prefix and LDFLAGS used with ./configure before. Please close this ITS. Ciao, Michael.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs