[Date Prev][Date Next]
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,
#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
The load profile that we placed on the server is documented in my prior
report. See above.
University Computing Services 354843. University of Washington
email: email@example.com voice: (206) 685-3344