signal 10 in malloc call???

[Doug Gwyn]

In article <3989 at killer.UUCP> toma at killer.UUCP (Tom Armistead) writes:
>Call me crazy, but shouldn't malloc just return me an error if there 
>are problems???

Since I haven't finished writing /dev/telepathy, I can't remotely
debug your application, but in general problems like the one you
report result from a bug in the application code.  malloc()
maintains a linked list of storage (heap) blocks with "busy" bit
indicators attached to the block headers (in addition to the links).
If your application scribbles on one of these headers, or if it even
frees an already-free block, then a later (perhaps MUCH later)
invocation of malloc() can run amok.

Source code licensees can recompile libc/gen/malloc.c to enable
a slew of debugging checks that often detect such heap abuse early.
This really should be provided as a separate /usr/lib/*.[oa] for
binary customers to use, but it probably hasn't been.  One trick
you can try is to provide your own simple memory allocator called
MyAlloc()/MyFree() that performs stringent consistency checks but
uses malloc() to obtain an initial large chunk of heap space to be
subdivided and reallocated by your allocator.  Then recompile your
application with "-Dmalloc=MyAlloc -Dfree=MyFree" in CFLAGS in your
Makefile, link it with your debugging-allocator object, and see
what turns up.  Note that the C library will continue to use the
real malloc(), but presumably it knows what it's doing and will
use it correctly.  (The only way I think this checking could fail
is if the malloc arena corruption is due to abusing some other C
library routine.)  Good luck.