[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: problem with latest stable

"Kurt D. Zeilenga" wrote:

> If I try to delete again, slapd dies with a segmentation fault:
> Looks like a bug in the new "delete leaf id from parents list of children"
> code....
> Can you provide a stack dump and/or back trace?

you want it, you got it!.

I've been trying to reproduce this on my test machine (not my clients machine)
and I can't yet.  I'm wondering if it is some sort of database data sensitivity
or database creation problem.  It's probably something really stupid...  I'll
keep trying to reproduce this in a form I can distribute.  In the meantime I'm
going to go thump on the person that got me in this fix ;-)

(gdb) backtrace
#0  chunk_free (ar_ptr=0x400b4bd0, p=0x8078220) at malloc.c:2902
#1  0x400606a1 in __libc_free (mem=0x8078228) at malloc.c:2877
#2  0x804dbaa in attr_free (a=0x8078200) at attr.c:22
#3  0x804e829 in entry_free (e=0x806ad88) at entry.c:196
#4  0x80583cc in cache_return_entry (cache=0x80765f8, e=0x806ad88) at cache.c:62
#5  0x805943e in ldbm_back_delete (be=0x80761d0, conn=0x8078b74, op=0x8077e00,
    dn=0x8078158 "estUser3,o=Customers,o=WebSurfer,o=Resellers,o=ZipLink.net") at
#6  0x8051fe3 in do_delete (conn=0x8078b74, op=0x8077e00) at delete.c:75
#7  0x804b936 in connection_operation (arg=0x806ad40) at connection.c:68
#8  0x8062677 in pthread_create (tid=0x8077e24, attr=0xbffffae0, func=0x804b7d8
<connection_operation>, arg=0x806ad40)
    at thread.c:555
#9  0x804bde5 in connection_activity (conn=0x8078b74) at connection.c:210
#10 0x804b592 in slapd_daemon (port=389) at daemon.c:393
#11 0x8062677 in pthread_create (tid=0x806acb0, attr=0xbffffd98, func=0x804a3c4
<slapd_daemon>, arg=0x185) at thread.c:555
#12 0x804a05f in main (argc=3, argv=0xbffffdb8) at main.c:189