Randall Gellens wrote:
At 8:29 AM -0700 9/12/05, Ken A wrote:
Additional info:
The error " ***glibc detected *** malloc() : memory corruption" is
coming up in a pop3 client running windows. Server is running qpopper
4.0.8, on fedora core 3 with latest patches.
Below is some info about the error message and a hint about how to
suppress this error message.
So, it looks like putting "MALLOC_CHECK_ 0" into the qpopper init
file would suppress the error message, but there seems to be a bug in
the qpopper code?
Can you reproduce this? If so, would it be possible to do so running
Qpopper under truss(1) or ktrace(1) or whatever the equivalent is on
your platform?
If there is a bug it would be good to track it down and fix it.
It's a busy production machine, and only a couple users have reported
it. The condition that seems to be common with the reports is checking
pop3 mail 2 times quickly in succession. I have not been able to
reproduce it. One user had Outlook Express set to check the same pop3
box twice, and the other was on a high latency satellite link and was
impatiently clicking send & receive.
If I get some time, I'll setup a test popper on another box and see if I
can repeat it.
Thanks,
Ken A
Pacific.Net
Thanks,
Ken
From 'man malloc'
Recent versions of Linux libc (later than 5.4.23) and GNU libc (2.x)
include a malloc implementation which is tunable via environment
variables. When MALLOC_CHECK_ is set, a special (less efficient)
implementation is used which is designed to be tolerant against
simple errors, such as double calls of free() with the same
argument, or overruns of a single byte (off-by-one bugs). Not all
such errors can be protected against, however, and memory leaks can
result. If MALLOC_CHECK_ is set to 0, any detected heap
corruption is silently ignored; if set to 1, a diagnostic is printed
on stderr; if set to 2, abort() is called immediately. This can be
useful because otherwise a crash may happen much later, and the true
cause for the problem is then very hard to track down.
