(ITS#6200)

[imf@u.washington.edu]

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.

The load profile that we placed on the server is documented in my prior 
report.  See above.

---
Tracy Stenvik
University Computing Services 354843.  University of Washington
email: imf@u.washington.edu  voice: (206) 685-3344