[comp.lang.c] malloc hangs indefinitely

daveh@marob.MASA.COM (Dave Hammond) (01/30/89)

In a reasonably large project I am involved with, a call from fgetc()
to malloc() appears to hang indefinitely.  After killing the process
and running adb, a $C command shows:

* _malloc(0x408)	from __findbuf+0x3a
__findbuf(0x18825b8)	from __filbuf+0x17
__filbuf(0x18825b8)	from _fgetc+0x1e
_fgetc(0x18825b8)	from _U_CmdLex+0xde
_U_CmdLex(0x187e550)	from _f_newform+0x187
_f_newform(0x1883d0c, 0x373)	from _U_FrmRun+0x63
_U_FrmRun(0x1883d0c, 0x0, 0x0)	from _EX_Form+0x74
????????(0x1, 0x187e658)	from _U_UsrExec+0x56
_U_UsrExec(0x1,	0x187e658)	from _U_LocalExec+0x2b2
_U_LocalExec(0x1890910)	from _U_MnuCommand+0x103
_U_MnuCommand(0x1890910)	from _main+0x389
_main(0x0, 0x187eb4c, 0x187eb54)	from __start+0x39
__start()	from start0+0xc

My guess is that malloc is in an infinite loop looking for suitable
space in its heap.  Any suggestions on what might cause malloc to
spin its wheels?  Have I perhaps trashed malloc's heap list?

--
Dave Hammond
...!uunet!masa.com!{marob,dsix2}!daveh

ked@garnet.berkeley.edu (Earl H. Kinmonth) (01/31/89)

In article <489@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>space in its heap.  Any suggestions on what might cause malloc to
>spin its wheels?  Have I perhaps trashed malloc's heap list?

In those versions of malloc where the heap list is maintained through
a header just before the portion returned to you, this is very probable.
Copy a too long string into an area returned by malloc or assign with
a negative subscript and you will often do this.

gwyn@smoke.BRL.MIL (Doug Gwyn ) (01/31/89)

In article <489@marob.MASA.COM> daveh@marob.masa.com (Dave Hammond) writes:
>My guess is that malloc is in an infinite loop looking for suitable
>space in its heap.  Any suggestions on what might cause malloc to
>spin its wheels?  Have I perhaps trashed malloc's heap list?

Very likely.  If you have the source code for malloc(), you might
find that it is set up so that when compiled with -Ddebug it checks
its arena every time it's invoked.  Turning on this debugging check
will often cause an early abort of the program not far from where
the heap is being corrupted.