> Samuel Tran wrote: > >>I got a stack back trace using gdb: >> >>[EMAIL PROTECTED]:/usr/local/src/openldap_2.3.x_20050808/servers/slapd/.libs >>$ sudo gdb ./slapd >>GNU gdb 6.3-debian >>Copyright 2004 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 "i386-linux"...Using host libthread_db >>library "/lib/tls/libthread_db.so.1". >> >>(gdb) set width 70 >>(gdb) run -d 0 -f /etc/openldap/slapd.conf >>Starting >>program: /usr/local/src/openldap_2.3.x_20050808/servers/slapd/.libs/slapd >> -d 0 -f /etc/openldap/slapd.conf >>[Thread debugging using libthread_db enabled] >>[New Thread 1078075520 (LWP 3347)] >>/etc/openldap/slapd.conf: line 178: warning: cannot assess the validity >>of the ACL scope within backend naming context >>/etc/openldap/slapd.conf: line 207: warning: cannot assess the validity >>of the ACL scope within backend naming context >>/etc/openldap/slapd.conf: line 244: warning: cannot assess the validity >>of the ACL scope within backend naming context >>[New Thread 1088740272 (LWP 3350)] >>[New Thread 1097128880 (LWP 3351)] >>slapd: ch_malloc.c:122: ch_strdup: Assertion `0' failed. >> >>Program received signal SIGABRT, Aborted. >>[Switching to Thread 1097128880 (LWP 3351)] >>0x402fd83b in raise () from /lib/tls/libc.so.6 >>(gdb) bt full >>#0 0x402fd83b in raise () from /lib/tls/libc.so.6 >>No symbol table info available. >>#1 0x402fefa2 in abort () from /lib/tls/libc.so.6 >>No symbol table info available. >>#2 0x402f72df in __assert_fail () from /lib/tls/libc.so.6 >>No symbol table info available. >>#3 0x080852af in ch_strdup (string=0x0) at ch_malloc.c:122 >> new = 0x0 >>#4 0x081225bf in slapi_int_modifications2ldapmods ( >> pmodlist=0x82565cc) at slapi_utils.c:2723 >> >> > What happens here is that slapi_int_modifications2ldapmods() is trying > to duplicate the type of the modification (a string that contains the > name of the attribute that's being modified). Usually, this cannot be > NULL, but it is in case of some special internal attributes > (structuralObjectClass, entryUUID and so). I think you should file an > ITS, because it appears that SLAPI is unable to cope with slapd's > internal representation of modifications, but I'd prefer that someone > more familiar with SLAPI takes care of this. I have a trivial fix that > I'd append to your ITS, but I'm not sure it would fit. So please go and > file one. >
I filed an ITS. It is #3924.
