jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/10/90)
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. Just wondering if this is a known bug, or a common programmer error of some sort? -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
ear@wpi.wpi.edu (Eric A Rasmussen) (03/11/90)
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. It is possible that you are having a problem which is semi-common in 386's, especially fast ones. If you have a feature known as pipelining enabled, it can sometimes cause the machine to hang, even when the program executes perfectly on PC's and AT's. Pipelining reads ahead in the list of instructions for the processor to execute, a sort of cache which can help increase execution speed. Problems can be brought on if you use *gasp* self-modifying code that modifies the code that has been already read into the pipeline. It is also possible, I would suppose, that it could cause programs with really short loops to crash. Two possible fixes to test this theory would be to A) Put the machine in its slowest mode, 8 Mhz for most 386's, which generally reduces the number of instructions the processor has time to read ahead and may solve the problem, or B) Turn off the pipelining. _ _ +-=-=-=-=-=-=-=-=-+ |_ ,_ . _ |_} _ _ ,_ _ _ _ _ ,_ | ear@wpi.wpi.edu | |_ | | |_ | \ |_\ _> | | | |_| _> _> |_' | | | ear%wpi@wpi.edu | --< A real engineer never reads the instructions first! >-- +-=-=-=-=-=-=-=-=-+
CMH117@psuvm.psu.edu (Charles Hannum) (03/11/90)
How do you expect anyone to help you if you don't include a sample of code
that demonstrates this "bug"?
I suspect it is programmer error, as I've never heard about this "bug" before.
(I don't use MSC myself, though I have it; I prefer Turbo C.)
Virtually,
- Charles Martin Hannum II "Klein bottle for sale ... inquire within."
(That's Charles to you!) "To life immortal!"
cmh117@psuvm.{bitnet,psu.edu} "No noozzzz izzz netzzzsnoozzzzz..."
c9h@psuecl.{bitnet,psu.edu} "Mem'ry, all alone in the moonlight ..."person@plains.UUCP (Brett G. Person) (03/12/90)
It may be that the memory is not being free()'d properly. I've seen this happen before with my own code. You really dont give a lot of detail, but I suspect that this is what is happening. -- Brett G. Person North Dakota State University uunet!plains!person | person@plains.bitnet | person@plains.nodak.edu
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/13/90)
Thanks to those that have responded to my query about malloc(). I asked it because I wanted to know whether there was a "known bug", or whether to look further in to my code. In the end I found the problem totally elsewhere in my program, where some pointer manipulation managed to hose up MS-DOS (I was clobbering low addresses). I found the problem when I compiled it on a Unix system that gave me a core dump on the offending operations. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/18/90)
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. > >It is possible that you are having a problem which is semi-common in 386's, >especially fast ones. If you have a feature known as pipelining enabled, it >can sometimes cause the machine to hang, even when the program executes >perfectly on PC's and AT's. Pipelining reads ahead in the list of >instructions for the processor to execute, a sort of cache which can help >increase execution speed. Problems can be brought on if you use *gasp* >self-modifying code that modifies the code that has been already read into the >pipeline. It is also possible, I would suppose, that it could cause programs >with really short loops to crash. Two possible fixes to test this theory >would be to A) Put the machine in its slowest mode, 8 Mhz for most 386's, >which generally reduces the number of instructions the processor has time to >read ahead and may solve the problem, or B) Turn off the pipelining. > Last night I did some further research into my problem. (A few days ago I thought it was solved because I found where I was clobbering code via wild pointers. But I fixed that one, and then the problem showed up again). Actually, now I am seeing a slightly different problem from the hanging up: I found that after several calls to malloc() to get more data, suddenly it gave me a block of data that it had ALREADY allocated! So I was getting the same block of data for two different parts of my program to write on, and of course everything gets scrambled. I verified that I was calling malloc() with a reasonable request each time (around 1k, it varied slightly), by using code view to breakpoint the calls. One time I tried putting my 386 down to 16mhz (it runs at 20 normally). I also set the wait state to 1 (I usually set it to 0). Nothing changed. My hypotheses at this point are: - My library routines are corrupted. - DOS 4.01 has a bug. - I still have a wild pointer somewhere writing to memory outside my data. I have seen various references on the net to a malloc() replacement or some similar package which can be used to verify use of dynamically allocated memory. Of course I didn't save the info. So I would appreciate it if someone could point me where to find it (via ftp). Thanks. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
henry@Apple.COM (Peter Henry) (03/20/90)
>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)