openldap-bugs January 2010

openldap-bugs@openldap.org

30 participants
86 discussions

ITS#6439
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

The behavior you describe violates RFC 4512 (section 5.1), while OpenLDAP complies with it. Please note that the root DSE is accessed using a plain, perfectly legal LDAP operation. The fact a client cannot be configured to perform such a simple operation clearly indicates the client is broken. A quick answer would be "get the client fixed". <advertisement> I can imagine simple workarounds, consisting in few lines of code that allow to circumvent the issue. They probably require to hire some expert consultant. </advertisement> p.

1 0

(ITS#6440) slapcat could write info about how it was run in form of LDIF comments
by masarati＠aero.polimi.it 05 Jan '10

05 Jan '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.230) Submitted by: ando Something like # slapcat run by <who>@<host> on <date> ... LDIF of database # number of entries, execution time, file size, ... For backward compatibility, this would need to be enabled by a specific switch. p.

1 0

(ITS#6439) rootDSE access method question
by j＠gropefruit.com 05 Jan '10

05 Jan '10

Full_Name: J Version: 2.4.20 OS: Debian-Lenny/amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.15.14.98) Certain clients (for example, a Solaris 10 host) need to query the rootDSE of our OpenLDAP server. Unfortunately, due to the way their client software is written, the Solaris 10 client will only be able to attempt to view the rootDSE using a scope of ONELEVEL or SUBTREE - it does not support BASELEVEL searches of the rootDSE. Solaris 10's 'ldapsearch' allows manual querying of our rootDSE for testing-purposes, so I know otherwise things should work (ACL-wise, etc). It just seems to be a problem in the system-config, as the man page clearly states that only the two aforementioned scopes are allowed. Options? Is there a way I can alias a DN-less object? If so, is this even advisable? Or, perhaps is there a way to store an alternate copy of the rootDSE somewhere that is more "conventionally" accessible? At this point, I'll consider any alternative. I reviewed the manpage for slapd.conf, however the rootDSE parameter in slapd.conf seems to be only used for "additions" or supplemental changes to an existing rootDSE. Thanks J

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

Aaron Richton wrote: > *so = { > s_next = 0x54f778 > s_base = { > bv_len = 0 > bv_val = (nil) > } > s_eid = 2147483967U > s_op = (nil) > s_rid = -34707408 > s_sid = -32897008 > s_filterstr = { > bv_len = 0 > bv_val = (nil) > } > s_flags = 0 > s_inuse = -1 Looks like syncprov_free_syncop() was getting called twice while in the middle of freeing. A potential fix is in HEAD. -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

*so = { s_next = 0x54f778 s_base = { bv_len = 0 bv_val = (nil) } s_eid = 2147483967U s_op = (nil) s_rid = -34707408 s_sid = -32897008 s_filterstr = { bv_len = 0 bv_val = (nil) } s_flags = 0 s_inuse = -1 s_res = 0x523120 s_restail = (nil) s_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 82U __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 5392720U } __pthread_mutex_owner64 = 5392720ULL } __pthread_mutex_data = 0 } }

1 0

Re: (ITS#6438) usage of invalid mutexint in syncprov
by hyc＠symas.com 04 Jan '10

04 Jan '10

richton(a)nbcs.rutgers.edu wrote: > Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt So we passed a NULL pointer in here, odd. Thread 5 is the one that crashed; in frame 4 can you print *so ? -- -- 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#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Backtrace: https://www.nbcs.rutgers.edu/~richton/openldap-6438-bt.txt

1 0

(ITS#6438) usage of invalid mutexint in syncprov
by richton＠nbcs.rutgers.edu 04 Jan '10

04 Jan '10

Full_Name: Aaron Richton Version: RE24 20091217 (2.4.21) OS: Solaris 9 URL: :wq Submission from: (NULL) (128.6.31.135) dec_mutexint was called with a NULL parameter while running the test suite. Unfortunately, the only evidence of this is a core file.

1 0

Re: (ITS#6437) sl_malloc issues
by hyc＠symas.com 04 Jan '10

04 Jan '10

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Nobody uses the pool code. I would suggest you profile it against the stack >> code before spending any time fixing it. > > The pool version crashes if I divide SLAP_SLAB_SIZE by 16 or multiply > the allocated amounts by 17. The stack version stays happy. I also > tried RE23 and rev 1.48 in case of code rot. (Should have tried > OpenLDAP 2.2, but would need to install an old Berkeley DB.) Adding a > sl_malloc fallback to ch_malloc instead of returning NULL didn't help. > > Anyway, I tried this because I assume the pool version is intended to > reduce the number of sl_malloc fallbacks to ch_malloc, but that almost > never happens in 'make test' with the current SLAP_SLAB_SIZE. Which > made that aspect hard to test. > > Also the pool version does a number of ch_mallocs for administration and > ch_frees them at reset. If the idea is to reduce ch_mallocs, it should > keep these blocks around. (Or allocate them with the slab.) Except the > 'slab_object's It only needs cleanup if the slab size changes, which > slapd never seems to do. This stuff was originally written to grow the slab as needed, but it was also being very braindead and would have kept a lot of excess memory lying around so I dropped that. So right, currently the slab size doesn't change. -- -- 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#6432) PATCH: MozNSS crypto (tls_m.c) - support InitContext, improved PEM support
by rmeggins＠redhat.com 04 Jan '10

04 Jan '10

> > OK. Another question - you're only using NSS_InitContext() for client > initialization. Any particular reason not to always use it? > I had coded around a bug in NSS_InitContext that caused it not to work in server mode - the MozNSS guys are aware of this issue - I'm waiting on the fix. > Also in tlsm_ctx_free() is it safe to pass a NULL to NSS_ShutdownContext()? I > think these two lines should be enclosed in "if (c->tc_initctx) {}" I'll change it to check for NULL.

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2010