On Mon, Dec 30, 2002 at 11:18:55PM -0500, Charles Wilson wrote:
If somebody with a debuggable cygwin kernel could look into this, I'd
appreciate it. I'll try to follow up on my own, but it takes FOREVER to
do a 'cvs update' on the cygwin source tree over a 28.8k modem...
Sigh. Finally built a debuggable cygwin from current CVS. Here's the
stacktrace from the SIGSEGV.
Problems "in the bowels" of malloc are invariably caused by memory
corruption, like double freeing of a pointer, overrunning of a buffer,
ignoring of OOM conditions, etc. Given that the malloc in cygwin (to
say nothing of Doug Lea's malloc) goes through a fairly heavy workout
every day, I'd suspect the application before I'd suspect cygwin.
I would too -- but I can't see where any of the arguments to the
functions, or any of the operations within the glib subroutines along
the way, do any of that. It all =seems= okay, but I'll probably have to
pull out pencil and paper and keep track of all the pointers by hand.
Or can I just turn on -DDEBUG when compiling malloc.cc...