Path: utzoo!mnetor!uunet!vsi!friedl
From: friedl@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.unix.wizards
Subject: Re: signal 10 in malloc call???
Message-ID: <640@vsi.UUCP>
Date: 5 May 88 17:46:04 GMT
References: <3989@killer.UUCP>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 56
Keywords: sys V rel 3.1, died in malloc?
Summary: Corrupt now, fail later...

In article <3989@killer.UUCP>, toma@killer.UUCP (Tom Armistead) writes:
> I am getting signal 10 (buss error) in the middle of a malloc call.
> It doesn't happen under any regular set of circumstances as far as I can
> tell. From sdb I can tell that that everything was set up ok, (but how can
> you mess up on a malloc call?)

It is almost certainly a corruption of malloc's arena pointers by
a program bug.  Malloc keeps its blocks in a linked list, and the
word just before its return to you points to the *next* area:

		+---------+
		| pointer |--->-\
		+---------+     |
malloc return-->|         |     |
		|   Your  |     |
		|  memory |     |
		|  chunk  |     v
		|   here  |     |
		|         |     |
		+---------+     |
		|         |<----/
	
If these pointers get messed up (easy to do, just overwrite a
chunk or free() a random pointer), it becomes a core-dump party.
	
> The instruction
> the thing dies on is a BITW (I think?) maybe something like:
> 	BITW	0(%r7),1

The low bit of the "pointer" above indicates whether the block is
free or busy.  This instruction is almost certainly testing this
bit on a crazy, overwritten, invalid pointer.

>  All the processes use malloc, realloc and free a WHOLE lot.

Oh boy :-(.  The bummer here is that the failure happens long
after the corruption occurs, and these can be the most difficult
bugs to track down.  The best bet (on the 3B2, at least), is to
use the specialized malloc(3x) functions with the -lmalloc
library.  These are implemented differently and may help the bugs
show up in different ways.

If life gets really rough you can write a routine that will run
through the malloc chain looking for problems.  This will help track
down where a random memory write is trashing the malloc chains:

	checkmalloc();
	crazy_function();
	checkmalloc();

If the first passes and the second doesn't, you're getting closer.

Good luck.
-- 
Steve Friedl    V-Systems, Inc. (714) 545-6442    3B2-kind-of-guy
friedl@vsi.com    {backbones}!vsi.com!friedl   attmail!vsi!friedl