Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!henry
From: henry@Apple.COM (Peter Henry)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Is there a bug in MSC 5.1 malloc for far data?
Message-ID: <7274@goofy.Apple.COM>
Date: 20 Mar 90 00:33:29 GMT
References: <25f8a7cd.ca@polyslo.CalPoly.EDU> <9573@wpi.wpi.edu> <2603111f.6e86@polyslo.CalPoly.EDU>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 23

>In article <9573@wpi.wpi.edu> ear@wpi.wpi.edu (Eric A Rasmussen) writes:
>>In article <25f8a7cd.ca@polyslo.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes:
>>>I have been having trouble with a compiler project that I am doing in
>>>MS C 5.1.  It appears that malloc() is sometimes getting hung in a very
>>>tight loop.  It doesn't happen all the time.  If I run my program
>>>right after rebooting it always works, but if I run it right after a
>>>compile, sometimes malloc hangs.  If I run it in CodeView and this happens
>>>I can stop it with Ctrl-Break, and step through the machine language,
>>>and it is stuck in the library routine in a very tight (about 6 instructions)
>>>loop.
>>>I am using the compact memory model, on a 386/20, and MS-DOS 4.01.
...

There *is* a bug in MSC 5.1 malloc(), having to do with allocating objects
larger than 32K.  I've found in repeatable trials that requesting objects
larger than 32K under some circumstances (e.g. after malloc'ing a few other
normal objects) casues the routines to return a (perhaps legal but) flaky
pointer, with a reasonable segment, but an offset (for pointer of course)
which will cause addressing wrap-around when accessing the object in its far
reaches.  I have a database that runs flawlessly in TURBO-C's large model,
but which fails with MSC as a result of this bug...

-Peter Henry (peter@nucleus.apple.com)