openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6011) test050 segfault
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24 3/9/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Current RE24 segfaults in test050 for me. Backtrace: Program terminated with signal 11, Segmentation fault. #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 (gdb) thr apply all bt Thread 7 (process 5559): #0 0x00002b457abc55b5 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002b457a40cb2b in ldap_pvt_thread_join (thread=1088002368, thread_return=0x0) at ../../../libraries/libldap_r/thr_posix.c:197 #2 0x0000000000435dbf in slapd_daemon () at ../../../servers/slapd/daemon.c:2665 #3 0x0000000000418104 in main (argc=8, argv=0x7fff306aeb18) at ../../../servers/slapd/main.c:948 Thread 6 (process 5574): #0 0x000000395e0d2228 in epoll_wait () from /lib64/libc.so.6 #1 0x0000000000435071 in slapd_daemon_task (ptr=0x0) at ../../../servers/slapd/daemon.c:2291 #2 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #3 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 5 (process 5589): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e0616e9 in _L_lock_39 () from /lib64/libc.so.6 #2 0x000000395e061602 in fputs () from /lib64/libc.so.6 #3 0x00002b457a660bce in ber_error_print (data=0x4171d920 "ber_scanf fmt ({mW}) ber:\n") at ../../../libraries/liblber/bprint.c:79 #4 0x00002b457a660edb in ber_pvt_log_printf (errlvl=1, loglvl=261, fmt=0x2b457a664bee "ber_scanf fmt (%s) ber:\n") at ../../../libraries/liblber/bprint.c:141 #5 0x00002b457a65be36 in ber_scanf (ber=0xde6fee0, fmt=0x516949 "{mW}") at ../../../libraries/liblber/decode.c:784 #6 0x00000000004b3434 in syncrepl_message_to_entry (si=0x2aaaac0195e0, op=0x4171e690, msg=0xde63100, modlist=0x4171e418, entry=0x4171e4e0, syncstate=1) at ../../../servers/slapd/syncrepl.c:1855 #7 0x00000000004afbe0 in do_syncrep2 (op=0x4171e690, si=0x2aaaac0195e0) at ../../../servers/slapd/syncrepl.c:887 #8 0x00000000004b1546 in do_syncrepl (ctx=0x4171ed90, arg=0x2aaaac016d00) at ../../../servers/slapd/syncrepl.c:1348 #9 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #10 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #11 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 4 (process 5590): #0 0x00000000004c3ed3 in slap_compose_sync_cookie (op=0x0, cookie=0x2aaaac017640, csn=0x0, rid=1, sid=2) at ../../../servers/slapd/ldapsync.c:47 #1 0x00000000004aefcc in do_syncrep1 (op=0x42438690, si=0x2aaaac017480) at ../../../servers/slapd/syncrepl.c:661 #2 0x00000000004b14b4 in do_syncrepl (ctx=0x42438d90, arg=0x2aaaac0182b0) at ../../../servers/slapd/syncrepl.c:1336 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 3 (process 5615): #0 0x000000395e0ddbe8 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x000000395e060de8 in _L_lock_101 () from /lib64/libc.so.6 #2 0x000000395e060d63 in fflush () from /lib64/libc.so.6 #3 0x00002b457a660c18 in ber_error_print (data=0x42c38850 "<= ldap_bv2dn(cn=config)=0 \n") at ../../../libraries/liblber/bprint.c:87 #4 0x00002b457a433465 in ldap_log_printf (ld=0x0, loglvl=4, fmt=0x2b457a447b90 "<= ldap_bv2dn(%s)=%d %s\n") at print.c:60 #5 0x00002b457a4201fc in ldap_bv2dn_x (bvin=0x2aaab000b1b0, dn=0x42c38f50, flags=0, ctx=0x0) at getdn.c:892 #6 0x0000000000453ccb in dnNormalize (use=2, syntax=0xd810b10, mr=0xd815030, val=0x2aaab000b1b0, out=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/dn.c:438 #7 0x000000000045e7e4 in ordered_value_normalize (usage=2, ad=0xd81c310, mr=0xd815030, val=0x2aaab000b1b0, normalized=0x2aaab000ba50, ctx=0x0) at ../../../servers/slapd/value.c:583 #8 0x0000000000458cf3 in slap_mods_check (op=0x42c39630, ml=0x2aaab000b200, text=0x42c39238, textbuf=0x42c39130 "p\221�B", textlen=256, ctx=0x0) at ../../../servers/slapd/modify.c:625 #9 0x00000000004b35c8 in syncrepl_message_to_entry (si=0x2aaaac0177a0, op=0x42c39630, msg=0x2aaab000afa0, modlist=0x42c393b8, entry=0x42c39480, syncstate=1) at ../../../servers/slapd/syncrepl.c:1892 #10 0x00000000004afbe0 in do_syncrep2 (op=0x42c39630, si=0x2aaaac0177a0) at ../../../servers/slapd/syncrepl.c:887 #11 0x00000000004b1546 in do_syncrepl (ctx=0x42c39d90, arg=0x2aaaac00db90) at ../../../servers/slapd/syncrepl.c:1348 #12 0x0000000000439047 in connection_read_thread (ctx=0x42c39d90, argv=0x9) at ../../../servers/slapd/connection.c:1225 #13 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #14 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #15 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 2 (process 5767): #0 0x000000395e0b8c17 in sched_yield () from /lib64/libc.so.6 #1 0x00002b457a40cb53 in ldap_pvt_thread_yield () at ../../../libraries/libldap_r/thr_posix.c:232 #2 0x00000000004b1203 in do_syncrepl (ctx=0x43c3bd90, arg=0xdc43fc0) at ../../../servers/slapd/syncrepl.c:1264 #3 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #4 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #5 0x000000395e0d1e3d in clone () from /lib64/libc.so.6 Thread 1 (process 5616): #0 0x000000395e0790f6 in memchr () from /lib64/libc.so.6 #1 0x00000000004c41ff in slap_parse_csn_sid (csnp=0xde63140) at ../../../servers/slapd/ldapsync.c:129 #2 0x00002aaaaaab9799 in syncprov_op_response (op=0x4343a630, rs=0x4343a1b0) at ../../../../servers/slapd/overlays/syncprov.c:1673 #3 0x000000000044e039 in slap_response_play (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:349 #4 0x000000000044e24f in send_ldap_response (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:423 #5 0x000000000044f101 in slap_send_ldap_result (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/result.c:692 #6 0x00000000004272f3 in config_back_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/bconfig.c:5197 #7 0x00000000004c206a in overlay_op_walk (op=0x4343a630, rs=0x4343a1b0, which=op_modify, oi=0xda30020, on=0x0) at ../../../servers/slapd/backover.c:669 #8 0x00000000004c226d in over_op_func (op=0x4343a630, rs=0x4343a1b0, which=op_modify) at ../../../servers/slapd/backover.c:721 #9 0x00000000004c234b in over_op_modify (op=0x4343a630, rs=0x4343a1b0) at ../../../servers/slapd/backover.c:755 #10 0x00000000004b7209 in syncrepl_updateCookie (si=0xdc44440, op=0x4343a630, pdn=0xd83fd20, syncCookie=0x4343a420) at ../../../servers/slapd/syncrepl.c:2979 #11 0x00000000004afc79 in do_syncrep2 (op=0x4343a630, si=0xdc44440) at ../../../servers/slapd/syncrepl.c:894 #12 0x00000000004b1546 in do_syncrepl (ctx=0x4343ad90, arg=0xdc44850) at ../../../servers/slapd/syncrepl.c:1348 #13 0x0000000000439047 in connection_read_thread (ctx=0x4343ad90, argv=0xe) at ../../../servers/slapd/connection.c:1225 #14 0x00002b457a40b6b7 in ldap_int_thread_pool_wrapper (xpool=0xd8272f0) at ../../../libraries/libldap_r/tpool.c:663 #15 0x00002b457abc42f7 in start_thread () from /lib64/libpthread.so.0 #16 0x000000395e0d1e3d in clone () from /lib64/libc.so.6

1 0

ldapsearch weird results - wild card not working as expected
by Simon McGregor 09 Mar '09

09 Mar '09

I wrote a script to add groups to my ldap directory --------------------------------- #!/bin/sh # Get the latest gid gidlast="`ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1`" newgid="`echo "$gidlast + 1" | bc`" echo "newgid: $newgid" # Make the Mods echo "dn: cn=$1,ou=Group,dc=mydomain,dc=com" > /tmp/modify.ldap echo "changetype: add" >> /tmp/modify.ldap echo "objectClass: posixGroup" >> /tmp/modify.ldap echo "objectClass: top" >> /tmp/modify.ldap echo "cn: $1" >> /tmp/modify.ldap echo "gidNumber: $newgid" >> /tmp/modify.ldap # Run the Update ldapmodify -x -f /tmp/modify.ldap -h myserver -D cn=Manager,dc=mydomain,dc=com -w mypasswd ---------------------------------- This correctly creates a new group eg. ./mkgroup.sh mygroup01 $ ldapsearch -x "cn=mygroup01" -h myserver produces -> # mygroup01, Group, mydomain.com dn: cn=mygroup01,ou=Group,dc=mydomain,dc=com objectClass: posixGroup objectClass: top cn: mygroup01 gidNumber: 7435 memberUid: dummyuser The issue is the following: $ ldapsearch -x "cn=mygroup*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7435 $ ldapsearch -x "cn=*" -b "ou=Group,dc=mydomain,dc=com" -h myserver | grep gidNumber | awk '{ print $2 }' | sort -u | tail -n 1 returns the result 7434 In other words the wild card is not picking up the new group even though it is actually there. Perhaps someone can show me the error of my ways but I think both results should return the same value I am running centos 5 with openldap-clients-2.3.27-8.el5_2.4 openldap-servers-2.3.27-8.el5_2.4 openldap-2.3.27-8.el5_2.4 openldap-devel-2.3.27-8.el5_2.4 The information contained in this email and any attachments is strictly confidential. If you are not the intended recipient you must not disclose or use the information contained in it. If you have received this email in error please notify us immediately by return email and delete the document. Domain Principal Pty Ltd accepts no liability for any loss or damage caused by this email or its attachments due to viruses interference interception corruption or unauthorised access.

2 1

Re: (ITS#6010) substitution for acl sets
by hyc＠symas.com 09 Mar '09

09 Mar '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: HEAD > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, > the man page is lacking documentation on this feature. It should be added. The man page lacks documentation on sets, period... The examples in the Admin Guide only touch on one use case. I think it's time we acknowledged that this feature exists, largely unchanged from its initial inception. (Yes, features have been added, but there's been no radical redesign.) -- -- 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#6004) test039 seg faults
by hyc＠symas.com 09 Mar '09

09 Mar '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >>> tar.gz >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Hallvard's situation was mainly due to his particular -rpath requirements. The libtool wrapper script will set LD_LIBRARY_PATH to include all of the build directories of its dependent libraries, but that didn't help because of his compiled in runpaths. -- -- 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#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > >> Quanah Gibson-Mount wrote: >>> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >>> >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Str?der >>>>> Version: HEAD >>>>> OS: openSUSE Linux 11.1 >>>>> URL: >>>>> Submission from: (NULL) (84.163.90.131) >>>>> >>>>> Will try to grab a stack trace. >>>> >>>> So here's the end of the output of test039 (with HDB) and a backtrace. >>>> >>>> See also a tar.gz of directory testrun/: >>>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>>> s. tar.gz >>> >>> Why are the symbols missing from most of the stack frames? The build >>> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >>> causing it to pick up some other libraries on the system that are >>> stripped? >> >> Hmm, a pre-installed libldap could be picked up if -releng is already >> removed from the shared lib names. Since this is switched back and forth >> in CVS there's no easy way to keep my system working and maintain a >> completely separate build tree. That's an issue Hallvard already raised >> (with no success). > > Current RE24 is releng, so if your CVS tree is fully up to date, it > should not pick up any other ldap libs. Sorry, I had the RE24 local installation in the LD_LIBRARY_PATH. Hmm... Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 11:39 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: HEAD >>>> OS: openSUSE Linux 11.1 >>>> URL: >>>> Submission from: (NULL) (84.163.90.131) >>>> >>>> Will try to grab a stack trace. >>> >>> So here's the end of the output of test039 (with HDB) and a backtrace. >>> >>> See also a tar.gz of directory testrun/: >>> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_fault >>> s. tar.gz >> >> Why are the symbols missing from most of the stack frames? The build >> should always have symbols. Do you have an LD_LIBRARY_PATH set that's >> causing it to pick up some other libraries on the system that are >> stripped? > > Hmm, a pre-installed libldap could be picked up if -releng is already > removed from the shared lib names. Since this is switched back and forth > in CVS there's no easy way to keep my system working and maintain a > completely separate build tree. That's an issue Hallvard already raised > (with no success). Current RE24 is releng, so if your CVS tree is fully up to date, it should not pick up any other ldap libs. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6004) test039 seg faults
by michael＠stroeder.com 09 Mar '09

09 Mar '09

Quanah Gibson-Mount wrote: > --On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Str?der >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.90.131) >>> >>> Will try to grab a stack trace. >> >> So here's the end of the output of test039 (with HDB) and a backtrace. >> >> See also a tar.gz of directory testrun/: >> http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. >> tar.gz > > Why are the symbols missing from most of the stack frames? The build > should always have symbols. Do you have an LD_LIBRARY_PATH set that's > causing it to pick up some other libraries on the system that are stripped? Hmm, a pre-installed libldap could be picked up if -releng is already removed from the shared lib names. Since this is switched back and forth in CVS there's no easy way to keep my system working and maintain a completely separate build tree. That's an issue Hallvard already raised (with no success). Ciao, Michael.

1 0

Re: (ITS#6004) test039 seg faults
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

--On Monday, March 09, 2009 4:23 PM +0000 michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Str?der >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.90.131) >> >> Will try to grab a stack trace. > > So here's the end of the output of test039 (with HDB) and a backtrace. > > See also a tar.gz of directory testrun/: > http://www.stroeder.com/temp/openldap/testrun-its6004_test039_seg_faults. > tar.gz Why are the symbols missing from most of the stack frames? The build should always have symbols. Do you have an LD_LIBRARY_PATH set that's causing it to pick up some other libraries on the system that are stripped? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6010) substitution for acl sets
by quanah＠OpenLDAP.org 09 Mar '09

09 Mar '09

Full_Name: Quanah Gibson-Mount Version: HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) substitution was added for ACL sets with ITS#2285. However, as per ITS#5804, the man page is lacking documentation on this feature. It should be added.

1 0

Re: (ITS#6009) test019: test failed - master and R2 slave databases differ
by quanah＠zimbra.com 09 Mar '09

09 Mar '09

Yeah, I know. ;) But there's a few fixes left to go in, including what I believe will fix what you saw. That's why I haven't called for testing yet on openldap-devel. --Quanah --On Monday, March 09, 2009 6:30 PM +0000 michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Monday, March 09, 2009 3:24 PM +0000 michael(a)stroeder.com wrote: >> >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Str?der >>>> Version: RE24 >>> >>> Seems to work in HEAD on the very same system. >> >> RE24 is not ready for testing yet. > > Well, Howard recently recommended to use it (see below). So I'm testing > as usual... > > Ciao, Michael. > > -------- Original Message -------- > Subject: Re: RE24 (2.4.15) slapd consuming large amounts of CPU > Date: Sat, 07 Mar 2009 00:47:57 -0800 > From: Howard Chu <hyc(a)symas.com> > To: John Morrissey <jwm(a)horde.net> > CC: openldap-software(a)openldap.org > References: <20090304185521.GA3184(a)boost.horde.net> > <49AEE757.3000502(a)symas.com> <20090306141020.GA7876(a)boost.horde.net> > > John Morrissey wrote: >> On Wed, Mar 04, 2009 at 12:40:55PM -0800, Howard Chu wrote: >>> John Morrissey wrote: >>>> A backtrace (below) shows many threads waiting on a mutex in >>>> bdb_cache_*(). >>> From the trace it looks similar to ITS#5860. The patches for this >>> are in HEAD, not yet released. >> >> With an shm_key, slapd CPU consumption dropped noticably and has been >> running long enough to make the leak apparent. >> >> Since this second-round fix for ITS#5860 has been merged into RE24, >> do you recommend running that, or should I cherry-pick >> 1.120.2.{21,22} into our local packaging? > > At this point I would just use RE24. Unless any new critical bugs show > up in the next few days, it's very likely what will be 2.4.16. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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