Hi,
When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex:
Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from /usr/pkg/lib/libldap_r-2.3.so.0 #4 0x0805a756 in ?? () #5 0x0819e4fc in __ps_strings () #6 0x00000002 in ?? () #7 0xbfbfe8e8 in ?? () #8 0x0805a713 in ?? () #9 0x00000286 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe958 in ?? () #12 0x0804e2c1 in ?? () #13 0xbfa00000 in ?? () #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 #15 0x00000002 in ?? () #16 0x00000000 in ?? ()
This was triggered by calling slapd with an invalid URLlist argument:
-h 'ldap://127.0.0.1 ldaps://<external ip>'
with no interfaces on the system configured with <external ip>
--On Wednesday, May 30, 2007 8:40 PM -0400 Jean-Luc Wasmer jl+openldap@lists.wasmer.ca wrote:
Hi,
When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex:
Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace # 0 0xbb87dfff in kill () from /usr/lib/libc.so.12 # 1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 # 2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 # 3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from # /usr/pkg/lib/libldap_r-2.3.so.0 4 0x0805a756 in ?? () # 5 0x0819e4fc in __ps_strings () # 6 0x00000002 in ?? () # 7 0xbfbfe8e8 in ?? () # 8 0x0805a713 in ?? () # 9 0x00000286 in ?? () # 10 0x00000001 in ?? () # 11 0xbfbfe958 in ?? () # 12 0x0804e2c1 in ?? () # 13 0xbfa00000 in ?? () # 14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 # 15 0x00000002 in ?? () # 16 0x00000000 in ?? ()
This was triggered by calling slapd with an invalid URLlist argument: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>
Please file an ITS at:
http://www.openldap.org/its/ which is the proper method for reporting bugs.
Thanks, Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Wednesday, May 30, 2007 8:40 PM -0400 Jean-Luc Wasmer jl+openldap@lists.wasmer.ca wrote:
Hi,
When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex:
Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace # 0 0xbb87dfff in kill () from /usr/lib/libc.so.12 # 1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 # 2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 # 3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from # /usr/pkg/lib/libldap_r-2.3.so.0 4 0x0805a756 in ?? () # 5 0x0819e4fc in __ps_strings () # 6 0x00000002 in ?? () # 7 0xbfbfe8e8 in ?? () # 8 0x0805a713 in ?? () # 9 0x00000286 in ?? () # 10 0x00000001 in ?? () # 11 0xbfbfe958 in ?? () # 12 0x0804e2c1 in ?? () # 13 0xbfa00000 in ?? () # 14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 # 15 0x00000002 in ?? () # 16 0x00000000 in ?? ()
This was triggered by calling slapd with an invalid URLlist argument: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>
Please file an ITS at:
http://www.openldap.org/its/ which is the proper method for reporting bugs.
This is likely the same as ITS#4957 (already fixed), but it's hard to tell without a proper stack trace (with symbols intact) and without a version number.
Don't just ask for bug reports, ask for *useful* bug reports...
Howard Chu wrote:
Quanah Gibson-Mount wrote:
Please file an ITS at:
http://www.openldap.org/its/ which is the proper method for reporting bugs.
I didn't make it clear: I was actually asking if this issue was known (ie logged somewhere) to avoid polluting the tracking system.
This is likely the same as ITS#4957 (already fixed), but it's hard to tell without a proper stack trace (with symbols intact) and without a version number.
Oh, sorry... I'm using 2.3.32 (but it looks like issue 4957 fix is not part of any current release).
I'll wait 2.3.36 before logging something.
Jean-Luc
Jean-Luc Wasmer wrote:
I didn't make it clear: I was actually asking if this issue was known (ie logged somewhere) to avoid polluting the tracking system.
The ITS is seldom "polluted" by issue notifications.
This is likely the same as ITS#4957 (already fixed), but it's hard to tell without a proper stack trace (with symbols intact) and without a version number.
Oh, sorry... I'm using 2.3.32 (but it looks like issue 4957 fix is not part of any current release).
I'll wait 2.3.36 before logging something.
I think this is an unwise attitude. Submitting issues in old releases risks to incur into already fixed bugs; but waiting for the next release to check if an issue disappeared risks to require yet another release to have it fixed. Running not yet released code is not really a big deal, especially if you stick with code tagged for release. For this purpose, you need to check out code from the CVS tagged as OPENLDAP_REL_ENG_X_Y (currently, OPENLDAP_REL_ENG_2_3). Follow directions at http://www.openldap.org/software/repo.html#AnonCVS. You'll get something known to work at least as much as the latest release, plus a number of known issues fixed.
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@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
I think this is an unwise attitude. Submitting issues in old releases risks to incur into already fixed bugs; but waiting for the next release to check if an issue disappeared risks to require yet another release to have it fixed. Running not yet released code is not really a big deal
Dear Pierangelo,
Considering that:
a) building the software could take 5 minutes or much more depending on how the pkgsrc patches for 2.3.36 (current supported release in pkgsrc) can be applied to the current file set tagged with OPENLDAP_REL_ENG_2_3;
b) this bug is only exposed when slapd is misconfigured;
I think I'll stick to the unwise attitude :-)
Jean-Luc
P.S.: having "dropped" CVS (in favor of Subversion) it was a nice flashback to consider your release process (i.e. tagging files).
--On Friday, June 01, 2007 3:11 PM -0400 Jean-Luc Wasmer jl+openldap@lists.wasmer.ca wrote:
Pierangelo Masarati wrote:
I think this is an unwise attitude. Submitting issues in old releases risks to incur into already fixed bugs; but waiting for the next release to check if an issue disappeared risks to require yet another release to have it fixed. Running not yet released code is not really a big deal
Dear Pierangelo,
Considering that:
a) building the software could take 5 minutes or much more depending on how the pkgsrc patches for 2.3.36 (current supported release in pkgsrc) can be applied to the current file set tagged with OPENLDAP_REL_ENG_2_3;
b) this bug is only exposed when slapd is misconfigured;
I think I'll stick to the unwise attitude :-)
How about:
Two of the OpenLDAP developers have kindly asked you to file an ITS and use our system correctly. Please go file one.
--Quanah
-- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
-
Howard Chu -
Jean-Luc Wasmer -
Pierangelo Masarati -
Quanah Gibson-Mount