Pierangelo Masarati wrote:
>> Sorry about the broken link. Here is the correct
one:
>>
>>
ftp://ftp.schrodinger.com/support/openldap/simon.gao.openlda
p_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
|
