Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.unix.wizards Subject: Re: signal 10 in malloc call??? Message-ID: <7840@brl-smoke.ARPA> Date: 5 May 88 15:41:53 GMT References: <3989@killer.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 28 Keywords: sys V rel 3.1, died in malloc? In article <3989@killer.UUCP> toma@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.