- openldap-bugs - openldap.org

Re: (ITS#5021) test021-certificate fails on HP-UX
by hyc＠symas.com 16 Jun '07

16 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't > know. Are you using the same version of OpenSSL on your other test machines? Have you tried a newer version? Makes sense that this wouldn't be a problem in HEAD since we're now using liblber for certificate handling. I suppose we could patch RE23 to use ber_get_int for the serial number. But at the moment this seems to be an OpenSSL problem, in which case we can close this ITS. > The offending operation (on Jennifer Smith) adds one certificate and > deletes the old one. However the added and the old certificate compare > equal because certificateExactNormalize() produces the same string for > both: > 0$email=ca(a)example.com,cn=example ca, > o=openldap example\2C ltd.,st=california,c=us > > That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() > returns serial number "0". The inputs to that function are > (gdb) p *sn > $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} > and > (gdb) p *sn > $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} > Those *sn values are the same as on a successful run on Linux, except > the 2nd data[1...] (the xample... string) which I presume does not > matter when length=1. > > The input certificates ('val' arg to certificateExactNormalize()) are > correct. > -- -- Howard Chu Chief Architect, 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#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't know. The offending operation (on Jennifer Smith) adds one certificate and deletes the old one. However the added and the old certificate compare equal because certificateExactNormalize() produces the same string for both: 0$email=ca(a)example.com,cn=example ca, o=openldap example\2C ltd.,st=california,c=us That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() returns serial number "0". The inputs to that function are (gdb) p *sn $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} and (gdb) p *sn $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} Those *sn values are the same as on a successful run on Linux, except the 2nd data[1...] (the xample... string) which I presume does not matter when length=1. The input certificates ('val' arg to certificateExactNormalize()) are correct. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

quanah(a)zimbra.com writes: > conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary > Why is it modifying the same attribute twice? It adds one cert and deletes another in the same op. The log from a successful run on Linux shows the same. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by quanah＠zimbra.com 15 Jun '07

15 Jun '07

--On June 15, 2007 9:59:56 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, 2.3.35 > OS: HP-UX > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in > HEAD. > > OpenSSL version: 0.9.7d. > > I enclose the testrun directory from: > > $ ./run -b ldif test021-certificate > Cleaning up test run directory leftover from previous run. > Running ./scripts/test021-certificate... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Testing certificate handling... > Add certificates... > ldapmodify failed (20)! > The last modify is erroring with already exists. The last logged modify looks really weird to me: conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary Why is it modifying the same attribute twice? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: RE23, 2.3.35 OS: HP-UX URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in HEAD. OpenSSL version: 0.9.7d. I enclose the testrun directory from: $ ./run -b ldif test021-certificate Cleaning up test run directory leftover from previous run. Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (20)!

1 0

Re: (ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

I wrote: > ./configure CC="cc -pthread" works. Well, it configures. Then it fails to build shared libraries because libtool invokes ld ... -pthread, and ld does not accept -pthread. But I guess that should be reported to the libtool folks. ./configure --disable-shared CC="cc -pthread" does work. -- Regards, Hallvard

1 0

Re: (ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu 15 Jun '07

15 Jun '07

On Jun 14, 2007, at 2:08 PM, Pierangelo Masarati wrote: > So what's really relevant in your patch, and > missing from the code, is a test for "err" after the "done" label. I > have applied something along those lines to the code. Please test. Yes, this works in my case - if indeed the test is after "done:". You accidentally put it before, and it doesn't work there. Thanks! Donn Cave, donn(a)u.washington.edu

1 0

(ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: OSF1 V5.1 alpha URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard /configure on OSF1 alpha finds no suitable threading library. config.log says: configure:19993: checking pthread.h usability configure:20005: cc -c -g -I/local/include -I/local/gnu/include conftest.c >&5 cc: Error: /usr/include/pthread.h, line 1251: #error "Please compile the module including pthread.h with -pthread" (errormessage) due to this snippet of pthread.h: # ifndef _REENTRANT # error "Please compile the module including pthread.h with -pthread" # endif ./configure CC="cc -pthread" works. Not sure how to deal with that one. Seems a bit excessive to run all the OL_PTHREAD_TRY()s _before_ detecting that the system has pthread. Maybe write a special case, like try for pthread.h with -D_REENTRANT if not found without that?

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 15 Jun '07

15 Jun '07

pierangelo.masarati(a)sys-net.it wrote : > Would it be possible to get, from the consumer's log, what was the > actually requested time limit in those cases? This means: track down > what connection/operation was concluded by a "Time Limit Exceeded" > response; then find out the corresponding request, and see what was the > requested time limit. You need "args" debug level for this purpose, and > you need to look at the second of the three numbers that end the SRCH > line in the logs; for example: Hi Pierangelo; The problem came from my LDAP client which specified timelimit=1. I repaired the client and everything works fine since several hours :-) Thanks for your help and sorry for wasting your time. For me the ITS is to be closed (the error "Time Limit Exceeded" produced for syncrepl connection every 3600 seconds does not bother me). Best regards Ali

1 0

Re: memory leak (ITS#5018)
by niloulili＠hotmail.com 14 Jun '07

14 Jun '07

OK,I've download release 2.3.32,after removing and test ,i'll report whether problem still exits. Thank you so much. best regards nina >From: Pierangelo Masarati <openldap-its(a)OpenLDAP.org> >To: niloulili(a)hotmail.com >Subject: Re: memory leak (ITS#5018) >Date: Thu, 14 Jun 2007 08:13:11 GMT > >OpenLDAP 2.2.19 (and OpenLDAP 2.2) has been abandoned long ago, so it is no >longer maintained. Please upgrade to a recent version and check if the problem >persists. Otherwise this ITS will be closed. > >p. _________________________________________________________________ ÓëÁª»úµÄÅóÓÑœøÐÐœ»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger: http://messenger.msn.com/cn

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu 14 Jun '07

14 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: >> While investigating another issue with back_perl, I tried to use the >> SampleLDAP.pm module that comes with the OpenLDAP source. I added the >> following to my slapd.conf: >> database perl >> suffix "o=AnyOrg,c=US" >> perlModulePath /home/eagle/SampleLDAP.pm >> perlModule SampleLDAP [...] > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /usr/local/etc/openldap > perlModule SampleLDAP I detect an intriguing difference in our configurations. I was misled by this comment in SampleLDAP.pm: # Usage: Add something like this to slapd.conf: # # database perl # suffix "o=AnyOrg,c=US" # perlModulePath /path/to/this/file # perlModule SampleLDAP The man page is more accurate. This was apparently actually a minor bug in the comments. :) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > While investigating another issue with back_perl, I tried to use the > SampleLDAP.pm module that comes with the OpenLDAP source. I added the > following to my slapd.conf: > > moduleload back_perl > ># ... > > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /home/eagle/SampleLDAP.pm > perlModule SampleLDAP > > The result of slapd -d 1 is: > ... > WARNING: No dynamic config support for database perl. > config_build_entry: "olcDatabase={2}perl" > backend_startup_one: starting "dc=Stanford,dc=EDU" > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: dbenv_open(/var/lib/ldap) > backend_startup_one: starting "o=AnyOrg,c=US" > Can't call method "init" on an undefined value. Using the SampleLDAP perl module supplied with the OpenLDAP source works just fine for me on Stanford's LDAP servers. ldap-uat00:/usr/local/etc/openldap# more slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema loglevel 0 threads 8 password-hash {CLEARTEXT} # Define global ACLs to disable default read access. pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # # Load dynamic backend modules: # Note: back-null is statically-linked. modulepath /usr/local/lib/openldap moduleload back_perl.la access to dn="" by * read access to * by anonymous read by users read by self write # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! tool-threads 2 ####################################################################### # perl database definitions ####################################################################### database perl suffix "o=AnyOrg,c=US" perlModulePath /usr/local/etc/openldap perlModule SampleLDAP Output from slapd -d -1 slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" WARNING: No dynamic config support for database perl. config_build_entry: "olcDatabase={1}perl" backend_startup_one: starting "o=AnyOrg,c=US" slapd starting daemon: added 4r listener=(nil) daemon: added 7r listener=0x6010e0 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL So I am unable to reproduce this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 14 Jun '07

14 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> Hallvard B Furuseth wrote: >>> hyc(a)symas.com writes: >>>> h.b.furuseth(a)usit.uio.no wrote: >>>>> * When a thread is finishing, make it go active for context_reset(). >>>>> Should make slapi module destructors safer, and I don't see that it >>>>> can hurt. >>>> I don't understand this. >>> Let me dig a bit back in the ITS... >>> "context_reset() can call connection_fake_destroy(), which via >>> slapi_int_free_object_extensions() calls slapi module destructors, >>> which can do who-knows-what." >> context_reset() can only be called from the main thread. It can (must) >> never be called by anything running from the pool. > > It's called from pool_wrapper(). pool_wrapper() could go active so > there can be no pause while that context_reset() call is running. Oh, ok. This is pretty much a non-issue because threads in the pool stay live until slapd shuts down. The one exception is for a cn=config modify that decreases the size of the pool to below the number of currently active threads, in which case some number of threads will exit immediately. I don't see any potential for conflict here. >>>>> * Scheduling: If several threads call pool_pause(), (...) > > (need to check out how it should work...) > >>>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>>>> represent the same thread ID: TID_HASH() would give different hashes >>>>> for the same thread, and pool_context() stops searching when it hits >>>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >>>> How can a single thread ID be represented by multiple bit patterns? >>> A struct/union with padding bytes seems the least unlikely possibility. > > Note that I did say "least unlikely" rather than "most likely": > It's not that I expect to encounter it, more that I'd prefer not to be > surprised in the form of a slapd malfuntion. > > So in that respect, my preference (not for RE23) is to cast to an > integer for the hash, and also to add pthread_<set/get>specific() so > thread_keys[] and its hash will only be a fallback solution. Casting to an int only works with simple types, the point of using the hash was to provide a solution that works for both simple and structured thread IDs. If you want to #ifdef the code so the two cases are handled differently, then just get rid of TID_HASH for the integral case. I'm still leary of the pthread TLS support, and making that change will require us to update all of the other thread package support, some of which I don't have access to build/test any more (e.g. SunOS4 LWP). >>>> The best fix may be to just use the address of the thread's stack as the >>>> thread ID. That's actually perfect for our purpose. >>> How does a function called from somewhere inside the thread know that >>> address? That's almost what the user context is, and thus what >>> thread_keys[] maps the thread ID to. >> It requires some degree of machine-dependence, which is why I never >> bothered to code it. The principle is simple though - all of our thread >> stacks are some multiple of 1MB in size. Take the address of any local >> variable, mask off the low 20 bits, and you have a unique thread ID (+/- >> some additional masking/shifting based on the actual thread stack size). > > I'm not sure how to determine _which_ multiple of 1MB - start two > threads and compare their stack addresses, maybe? In any case, I > agree it sounds rather more machine-dependent than the current code. That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. It's really not hard. If we were to disallow increasing the number of threads at runtime, we could simply allocate a block of thread stacks all at once, which would then allow our thread IDs to be simple integers from 0-N. -- -- Howard Chu Chief Architect, 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#5019) slapd: ldbm/gdbm, cache.c core dump
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 8:59 PM +0000 asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > LDBM is deprecated, and has been removed from the source tree. Bugs against LDBM will not be fixed, because of its inherent flaws. Upgrade your configuration to use one of the supported database mechanisms, back-bdb or back-hdb. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by hyc＠symas.com 14 Jun '07

14 Jun '07

asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > > > Platform: Linux, OpenLDAP-2.3.35 > Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no > --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls > --with-threads=no > gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e > > slapd core dumps with a corrupted stack, SIGABRT. > slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void > *)0)' failed.. > > Happens every time ldif is loaded... > $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret > adding new entry "dc=mf" > > adding new entry "dc=iana,dc=mf" > ldap_result: Can't contact LDAP server (-1) 1) ldbm is deprecated, don't use it. 2) if you insist on using it, get a debug stack trace for the abort 3) note that ldbm is still tested regularly in the 2.3 builds, and no one else has reported this occurrence, so there's probably something odd in your configuration. Providing your slapd.conf might help. But the ldbm code has been removed for 2.4; support for it is disappearing fast. -- -- Howard Chu Chief Architect, 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#4837) SunLDAP to OpenLDAP migration problem
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 10:02 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Quanah Gibson-Mount writes: >> It should be as simple as changing: >> passwd.c:#define SALT_SIZE 4 >> to >> passwd.c:#define SALT_SIZE 8 > > I don't get this. I don't know ssha1, but... Right, see my follow-up. I had the wrong string in my data when I did a cut and paste. ;) It actually works as it should. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

Quanah Gibson-Mount writes: > It should be as simple as changing: > passwd.c:#define SALT_SIZE 4 > to > passwd.c:#define SALT_SIZE 8 I don't get this. I don't know ssha1, but... That's for generating ssha1 hashes in hash_ssha1(), it is not used for decoding them in chk_ssha1() - which I assume is what he needs when moving _to_ OpenLDAP. chk_ssha1() looks independent of salt size - it base64-decodes the provided salt+hash and finds expects the salt to start at position LUTIL_SHA1_BYTES (from include/lutil_sha1.h) in that string. -- Regards, Hallvard

1 0

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 9:23 PM +0000 quanah(a)zimbra.com wrote: > Kurt, > > Zimbra has run into this issue in helping a customer who was running > SunDS migrate to OpenLDAP. It does not work at all, unfortunately. > Changing code to use an 8-bit salt does work. Never mind, the 8-bit salt works just fine. I had bad data in my cut & paste buffer last night when I tried this. Trying with the correct data works just fine. yeah! I'll mark this ITS as invalid, and note in the comments that 8-bit salted SSHA passwords work just fine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ando(a)sys-net.it wrote: > Yes, I figured that out. I'll fix this later. Fixed; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

Kurt, Zimbra has run into this issue in helping a customer who was running SunDS migrate to OpenLDAP. It does not work at all, unfortunately. Changing code to use an 8-bit salt does work. So, I'd be happy to fix this, but a general design question -- (a) Should this be implemented as a "ssha-salt" option in slapd.conf or (b) Should OpenLDAP try decrypting the password first as a 4-bit salt, and then try an 8-bit salt, then fail? (a) would be fairly portable across many salt settings, but AFAIK we've only hit 4 & 8 (b) would allow mixed salt values to be in userPassword, and I'd think that over time as people changed their passwords, it would allow the 8-bit salts to go away. Thoughts welcome. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5014) syncrepl failure syslog
by ando＠sys-net.it 14 Jun '07

14 Jun '07

donn(a)u.washington.edu wrote: > Hard to tell why syncrepl isn't working, if it discards error messages. This patch was not submitted according to the guidelines of usual contributions, which makes it hard to apply. In any case, it appears to be incorrect, since the response code should not be extracted that early, namely before getting the message type. AFAIK, only an LDAP_RES_SEARCH_RESULT could contain an error, and that value is already parsed out and stored in "err". What's missing is a log in case "err" indicates an error. So what's really relevant in your patch, and missing from the code, is a test for "err" after the "done" label. I have applied something along those lines to the code. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by asedlack＠mailfoundry.com 14 Jun '07

14 Jun '07

Full_Name: Aron Sedlack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.18.18.14) Platform: Linux, OpenLDAP-2.3.35 Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls --with-threads=no gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e slapd core dumps with a corrupted stack, SIGABRT. slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void *)0)' failed.. Happens every time ldif is loaded... $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret adding new entry "dc=mf" adding new entry "dc=iana,dc=mf" ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#5018) memory leak
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

niloulili(a)hotmail.com writes: > if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) > return 1; > if ( ldap_simple_bind_s( ld,"CN=nina > wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) > { > ldap_perror( ld, "ldap_simple_bind_s" ); insert "ldap_unbind( ld );" here. Does that fix the problem? That's how to free the LDAP* structure. In LDAP, "unbind" is the "disconnect" command, it's not the opposite of "bind". The misleading name came about because originally one had to bind after connect. > return 1; > } > ldap_msgfree( res ); res == NULL here in this particular code, so you can drop this and the declaration of 'res'. > /* close and free connection resources */ > ldap_unbind( ld ); > return 0; > } -- Regards, Hallvard

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ali.pouya(a)free.fr wrote: > What bothers me is that the regular client requests to the consumer receive > (scarcely and randomly) "Time Limit Exceeded" at checkpoint time. Would it be possible to get, from the consumer's log, what was the actually requested time limit in those cases? This means: track down what connection/operation was concluded by a "Time Limit Exceeded" response; then find out the corresponding request, and see what was the requested time limit. You need "args" debug level for this purpose, and you need to look at the second of the three numbers that end the SRCH line in the logs; for example: SRCH "dc=example,dc=com" 2 0 20 5 0 filter: (uid=foobar) attrs: 1.1 means: search "dc=example,dc=com" with scope subtree (2) and never deref aliases (0), using a size limit of 20, a timelimit of 5 and no attrsonly (0). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

Howard Chu writes: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> * When a thread is finishing, make it go active for context_reset(). >>>> Should make slapi module destructors safer, and I don't see that it >>>> can hurt. >>> I don't understand this. >> >> Let me dig a bit back in the ITS... >> "context_reset() can call connection_fake_destroy(), which via >> slapi_int_free_object_extensions() calls slapi module destructors, >> which can do who-knows-what." > > context_reset() can only be called from the main thread. It can (must) > never be called by anything running from the pool. It's called from pool_wrapper(). pool_wrapper() could go active so there can be no pause while that context_reset() call is running. >>>> * Scheduling: If several threads call pool_pause(), (...) (need to check out how it should work...) >>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>>> represent the same thread ID: TID_HASH() would give different hashes >>>> for the same thread, and pool_context() stops searching when it hits >>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >>> >>> How can a single thread ID be represented by multiple bit patterns? >> >> A struct/union with padding bytes seems the least unlikely possibility. Note that I did say "least unlikely" rather than "most likely": It's not that I expect to encounter it, more that I'd prefer not to be surprised in the form of a slapd malfuntion. So in that respect, my preference (not for RE23) is to cast to an integer for the hash, and also to add pthread_<set/get>specific() so thread_keys[] and its hash will only be a fallback solution. > Any implementation that leaves uninitialized padding bytes would be a > bug. Tools like valgrind would barf all over them. No. Valid compiler, valid code. Therefore valgrind is silent about copying uninitialized values, it only complains when you use them for something - like write() or arithmetic. So a valgrind complaint about an uninitialized _value_ isn't necessary at the point the uninitialized _variable_ is read. E.g. this complains in printf(), not in foo(): int foo() { struct { char c; /*maybe padding here*/ int j; } s; s.c = 1; s.j = 2; return ((unsigned char *)&s)[1]; /* maybe padding byte */ } int main() { printf("%d\n", foo()); } >> A pointer in hardware where several address representations map to the >> same physical address, and the compiler handles that by normalizing >> pointers when they are compared/subtracted. Like DOS "huge" pointers >> would have been if the compiler normalized them when comparing them >> instead of when incrementing/decrementing them. 20-bit address bus, >> 32-bit pointers, physical address = 16 * <segment half of pointer> + >> <offset half of pointer>. > > Nobody voluntarily uses such memory models today. The very mention of "DOS" > invalidates this discussion since there is no threading environment there. Right, at this point I answered how it _can_ happen, not why I expect to encounter it. I could see the demands of hardware design cause strange memory models to proliferate again, but I'm not holding my breath. I'd be a bit less surprised to encounter integers with padding bits again, but not for a simple ID type, and hashing an integer instead of its bytes would fix it anyway. >>> The best fix may be to just use the address of the thread's stack as the >>> thread ID. That's actually perfect for our purpose. >> >> How does a function called from somewhere inside the thread know that >> address? That's almost what the user context is, and thus what >> thread_keys[] maps the thread ID to. > > It requires some degree of machine-dependence, which is why I never > bothered to code it. The principle is simple though - all of our thread > stacks are some multiple of 1MB in size. Take the address of any local > variable, mask off the low 20 bits, and you have a unique thread ID (+/- > some additional masking/shifting based on the actual thread stack size). I'm not sure how to determine _which_ multiple of 1MB - start two threads and compare their stack addresses, maybe? In any case, I agree it sounds rather more machine-dependent than the current code. -- Regards, Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs