Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!uunet!huxley!steve From: steve@bitstream.com (Steve Stein) Newsgroups: comp.sys.mac.programmer Subject: Re: Help me port UNIX to THINK C 4.0 Message-ID: Date: 1 Aug 90 18:50:55 GMT References: <1990Jul31.104414.16305@d.cs.okstate.edu> Sender: steve@huxley.UUCP Distribution: comp Organization: Bitstream, Inc. Lines: 26 In-reply-to: minich@d.cs.okstate.edu's message of 31 Jul 90 10:44:14 GMT In article <1990Jul31.104414.16305@d.cs.okstate.edu> minich@d.cs.okstate.edu (MINICH ROBERT JOHN) writes: > alone app), malloc() goes off into deep thought and never exits. This ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In THINK C 4.0, this is often a symptom of a smashed heap. (Rich - jump in here and correct me if I'm wrong, but here goes:) For small memory allocation requests, TC 4 allocates memory out of buffers that it manages, rather than use the Mac memory manager. These buffers (like the Mac's heap) have control information intertwined with the data you've put into the objects you point to with malloc'ed pointers. If you have allocated say, 4 bytes to a pointer and you write 6 bytes, you will overwrite the control information in TC's memory manager buffer and your next malloc will hang in a fairly tight loop. These bugs are infuriating and often hard to find. Also, just to be sure, have you #include'd in all of your source files that use malloc? If not, you might be assigning bad values to your pointers, since the compiler will assume you meant malloc to return an int (2 bytes). Hope this helps, Good Luck! Steve Stein, Bitstream, Inc.