Full_Name: Daniel Tarbuck Version: 2.4.24 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.52.149.70) slapd[18256]: segfault at 6172752b ip b73fac81 sp bff68718 error 4 in libc-2.11.3.so[b738c000+13d000] slapd[7490]: segfault at 6172752b ip b74fac81 sp bfdecb08 error 4 in libc-2.11.3.so[b748c000+13d000] slapd[2865]: segfault at 6172752b ip b7c9cc81 sp bfffe5b8 error 4 in libc-2.11.3.so[b7c2e000+13d000] slapd[4740]: segfault at 6172752b ip b742cc81 sp bf824e68 error 4 in libc-2.11.3.so[b73be000+13d000] slapd[8020]: segfault at 6172752b ip b7c9cc81 sp bfffe5b8 error 4 in libc-2.11.3.so[b7c2e000+13d000] slapcat[28227]: segfault at 6172752b ip b742fc81 sp bff45118 error 4 in libc-2.11.3.so[b73c1000+13d000] backtrace shows what looks to be a double free() call from lber. This is a production system, so I don't have a whole lot of information (fixing was the priority). The segfault would occur right at the end of execution (closing the db). using berkdb 4.8 backend. No problems after reverting to 2.4.23.
tarbuck@futurewest.ca writes: > backtrace shows what looks to be a double free() call from lber. > This is a production system, so I don't have a whole lot of > information (fixing was the priority). Well, can you show that backtrace? Otherwise there's no chance at all of investigating this further. slapd uses liblber for a lot of its allocations, so the double free could come from just about anywhere. -- Hallvard
changed state Open to Feedback
Hello, Due to a lack of response to the necessary information required to pursue this report, this ITS will be closed. If you still encounter the issue with a current OpenLDAP release, please follow up with the information requested. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
no response
changed notes changed state Feedback to Closed