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

Re: (ITS#6200)

imf@u.washington.edu wrote:
> The changes made to 2.4.17 seem to have fixed the crashes in the caching
> module.  Thanks for that.
> We still are able to crash 2.4.17, however.  It only happens after a heavy
> load is placed on the producer for>24 hours continuous.  Unfortunately,
> we've not been able to get good tracebacks.  They all look like this,
> (gdb) where
> #0  0x00869410 in __kernel_vsyscall ()
> #1  0x00390d80 in raise () from /lib/libc.so.6
> #2  0x00392691 in abort () from /lib/libc.so.6
> #3  0x0038a1fb in __assert_fail () from /lib/libc.so.6
> #4  0x0808d532 in malloc ()
> #5  0x0822c93f in ?? ()
> #6  0x0822c933 in ?? ()
> #7  0x00000039 in ?? ()
> #8  0x0822c908 in ?? ()
> #9  0x00000000 in ?? ()
> The producer slowly grows its memory footprint.  I can't tell if it's from
> just normal operations or memory leaks.  I suspect it's a little of both.
> The end result, as you can see from the core above, is that there's likely
> some corrupted (or unfreed) memory somewhere.  Sorry I can't nail it down
> further.

There's not enough information here.

An assert is always accompanied by an error message on stderr; we need to see 
the actual error message.

There are no symbols in the stack trace pertaining to slapd itself. You seem 
to be running a stripped binary. Please provide a trace using a non-stripped 
binary that was compiled with -g (debug symbols enabled).
> The load profile that we placed on the server is documented in my prior
> report.  See above.

   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/