[Date Prev][Date Next]
trouble with slapd overlay
hope I picked the appropriate mailing list ...
I've got a problem with a slapd overlay I'm currently working at:
the overlay causes slapd to bomb, when compiled for & running on Debian
Etch AMD64 and Ubuntu Dapper (no other 64bit experiences so far), if - and
only if so - it's response handler is invoked simultaneously in several
The error always occurs at the same code line, line 89, in file
template_symtab.c: the memory location referred by 'symtab',
which has been allocated immediately before by ch_malloc(), is obviously
As long as only one single thread is hitting this code piece,
everything is fine.
In 32bit-environments, the overlay works.
The overlay has (mutex-protected) critical sections of code: an
overlay-specific cache, which, however, doesn't influcence the test
behaviour (I usually deactivate it via config file directive (see inline
comments in file template.c) to avoid the additional complexity).
What I want to say: I almost for sure can exclude thread synchronization
issues within my overlay as reason ... but somehow, the memory management
seems to get confused, no clue why.
I tried valgrind - it run's slapd fine, no sigsegv, no trouble, no related
error messages. When the MALLOC_DEBUG_ environment variable is set, slapd runs
great, too. Simple replacement of ch_malloc() and friends by stdlib malloc()
and free() bypasses the problem as well.
Maybe I've coded a memory overrun somewhere else within the overlay? Maybe I
did not understand the slapd memory management API (which, seriously, seems
to be a real pain! - I tried to use ch_malloc()/ch_strdup()/ch_free() where
possible, use proper nesting of these functions - only exception was memory
allocated by backend_attribute(), which I deallocate via
ber_bvarray_free_x(), using the current thread's memory context).
On the other hand, maybe the problem is related to ch_malloc() and the
underlying memory management itself?
The source code can be found here:
Would be very grateful for any advice. :)
Thalion Graphic Solutions eK.