openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

13 Jun '07

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. >>> * Scheduling: If several threads call pool_pause(), then once there is a >>> pause tpool does not schedule them all. They could get handled then, >>> or another thread could undo the pause so tpool would wait to pause >>> again. Is that deliberate? >> I don't understand the question. The point of the pause is to prevent >> any other thread (in the pool) from running. Why should tpool schedule >> any other threads at this point? > > Two threads call pool_pause(). Eventually the pool gets paused, and one > pool_pause() call returns. When that thread calls pool_resume(), the > other thread waiting in pool_pause() may or may not get scheduled. OK, that sounds like a bug. >>> - 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. Any implementation that leaves uninitialized padding bytes would be a bug. Tools like valgrind would barf all over them. > 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. >>> The best fix would be to use use real thread-specific data instead. >>> Just one key with the ctx for now, that minimizes the changes. OTOH >>> it also means we'll do thread-specific key lookup twice - first in >>> pthread to get the ctx, and then in ltu_key[] to find our data. >>> Anyway, I said I'd do that later but might as well get on with it, >>> at least for pthreads. Except I don't know if that's OS-dependent >>> enough that it should wait for RE24? >> 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). -- -- 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#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 13 Jun '07

13 Jun '07

I wrote: > For whatever isn't handled above, my suggestion for now is to keep the > failure if ldap_pvt_thread_t is a struct/union or wider than long, and > see if anyone still complains. Done. Compiles unless pointers are wider than long, but the basic problem remains. -- Regards, Hallvard

1 0

Re: (ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 12 Jun '07

12 Jun '07

I wrote: > Finally, libldap/tls.c does not check if ber_decode_oid() fails. Fixed that. Waiting for the other stuff, depends on the code's intent. -- Regards, Hallvard

1 0

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

12 Jun '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Hard to tell why syncrepl isn't working, if it discards error messages. *** servers/slapd/syncrepl.c.dist 2007-02-15 17:53:39.000000000 -0800 --- servers/slapd/syncrepl.c 2007-06-12 13:35:22.000000000 -0700 *************** *** 688,694 **** struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err; ber_len_t len; struct berval *psub; --- 688,694 ---- struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err, rrc; ber_len_t len; struct berval *psub; *************** *** 704,709 **** --- 704,710 ---- BerVarray syncUUIDs = NULL; ber_tag_t si_tag; + rrc = LDAP_SUCCESS; if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 727,732 **** --- 728,734 ---- while ( ( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, tout_p, &res ) ) > 0 ) { + ldap_parse_result( si->si_ld, res, &rrc, 0, 0, 0, 0, 0 ); if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 1061,1066 **** --- 1063,1076 ---- } done: + if ( rrc != LDAP_SUCCESS ) { + const char *errstr; + ldap_get_option( si->si_ld, LDAP_OPT_ERROR_NUMBER, &rrc ); + errstr = ldap_err2string( rrc ); + + Debug( LDAP_DEBUG_ANY, + "syncrepl %s result: %s\n", si->si_ridtxt, errstr, 0 ); + } slap_sync_cookie_free( &syncCookie, 0 ); slap_sync_cookie_free( &syncCookie_req, 0 );

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 12 Jun '07

12 Jun '07

ando <ando(a)sys-net.it> writes: > Committed to HEAD. Command-line clients now use DNS SRV to look up the > host names related to a DN and build a list of URIs for subsequent use. > To trigger, use -H "<proto>:///DN". The <host> portion must be empty, > and a DN must be present. The DN must be in the "dc=<component>" form; > it's turned into a domain and the host list is looked up using DNS SRV. > After that, a list of URIs is built using the returned host/ports, and > using <proto> as the LDAP scheme. Thank you! I've forwarded this information to the original Debian bug reporter who was interested in the feature in the hopes that he'll be able to test and provide feedback on the implementation. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it 12 Jun '07

12 Jun '07

ando(a)sys-net.it wrote: > ... it's "packets". The man page (or the code) is wrong. ... but the man page is correct in HEAD; so it was fixed, but not backported. 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#5011) loglevel packet doesn't work
by ando＠sys-net.it 12 Jun '07

12 Jun '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.35 > OS: mac os x > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > The slapd.conf man page says: > > loglevel <integer> [...] > 2 (0x2 packet) debug packet handling > > but if you specify packet, slapd refuses to start, stating: > > /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> > unknown level "packet" ... it's "packets". The man page (or the code) is wrong. 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#5011) loglevel packet doesn't work
by quanah＠zimbra.com 11 Jun '07

11 Jun '07

Full_Name: Quanah Gibson-Mount Version: 2.3.35 OS: mac os x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) The slapd.conf man page says: loglevel <integer> [...] 2 (0x2 packet) debug packet handling but if you specify packet, slapd refuses to start, stating: /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> unknown level "packet" --Quanah

1 0

Re: (ITS#5008) Do you have the win32 version of OpenLDAP
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

caojunliang(a)huawei.com writes: > I want to know whether or not the win32 version of OpenLDAP exsits. Please take this to the mailinglist openldap-software(a)openldap.org. The Issue Tracking System is for bug reports etc, not for help requests. This ITS will be closed. -- Regards, Hallvard

1 0

(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt Submission from: (NULL) (129.240.202.105) Submitted by: hallvard The 40*X+Y rule for first 2 components is decoded wrong, it should be X = val < 80 ? val/40 : 2 # X = 0, 1 or 2 Y = val - 40*X # Y is unlimited when X==2, <40 otherwise See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1. 40*X+Y can take more than one octet. The functions allow buffer overruns. ber_decode_oid() if the oid has many small components. ber_encode_oid() for negative input (which becomes a large ulong), or if sizeof(long) == 8. The latter can just as easily be avoided by producing the bytes backwards and then reversing. They do not check much for invalid input or too large values. Possibly they ought to be a bit paranoid about that since they are used for certificates, I don't know. E.g. check that the BER encoding has "fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in subidentifiers. ber_encode_oid() seems a bit strange about which errors it accepts and which ones it rejects. E.g. garbage after first 2 components is OK. The "assert(foo != NULL)"s are after "der = foo->bv_val":-) I enclose untested new versions. Will test and commit when I have time if someone says OK, but it depends e.g. on how paranoid the routines should or should not be. Or if they should trust the ber values to end with \0, for that matter. Finally, libldap/tls.c does not check if ber_decode_oid() fails.

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