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.