Pierangelo Masarati wrote:

...

Sorry about the broken link. Here is the correct one:

ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext

...

...

When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer:

ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A

The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process,

^^^ what does this mean?

If I start slapd manually as following commands:

/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps'

Then I did not see the problem as I would when setting loglevel to 0, 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which launch the daemon with the same options. When starting slapd from /etc/init.d/slapd as background daemon process, slapd will write to /var/log/ldap.log and /var/log/message. It seems that the difference exists between writing ldap logs to a file (slapd runs in background) or writing to console (slapd runs in foreground as started manually).

...

...

then all debug level works without problem.

OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything like that. I note that differences related to the debug level usually mean that a NULL or an invalid pointer is passed to a *printf(3) routine on those systems that do not tolerate it (e.g. Solaris). But usually the bug disappears when __decreasing__ the log level, while -1 means all.

p.

I would expect writing less log should help avoiding problem. In this case, somehow logging must be set at certain or above a level. Below that it will trigger problem. While I was trying to get pieces working, I always set loglevel to 1 or -1. So I did not realize this problem until very late. The error I got as a result of attempting change password is "can't contact LDAP server" which is very confusing (might be because slapd already crashed before serving last request).

I am happy to run more tests and provide further information as needed.

If slapd crashes, the only really useful info is a core dump, as indicated in the FAQ I already pointed you to (that's basically why I pointed you there: there's no point in always repeating instructions for bug tracing, that's what the FAQ is intended for; apparently, it's totally ignored).

Not entirely. I thought system environment information might be useful too.

Anyway. Here is the coredump. Let me know if this is enough.

==================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213843792 (LWP 7706)] [New Thread -1240826992 (LWP 7709)] [New Thread -1249219696 (LWP 7710)] [New Thread -1257612400 (LWP 7711)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed.

Program received signal SIGABRT, Aborted. [Switching to Thread -1249219696 (LWP 7710)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7a8d429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7a8e9d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7a86e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response () No symbol table info available. #5 0x0000000a in ?? () No symbol table info available. #6 0x08150731 in ?? () No symbol table info available. #7 0x08150731 in ?? () No symbol table info available. #8 0xb58a61b4 in ?? () No symbol table info available. #9 0xb58a5cac in ?? () No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. =====================================================================

Simon