minich@d.cs.okstate.edu (MINICH ROBERT JOHN) (07/31/90)
I'm trying to port Rayshade 3.0 to my Mac (SE/30) and am having strange difficulties. I've managed to get all the code compiled OK with minor alterations (the project file is ~700K and the final app ~160K) but I am running into problems with malloc(). Although I have given plenty of memory to the partition (under the debugger and as a stand alone app), malloc() goes off into deep thought and never exits. This happens after a few successful malloc()'s, so something is working right. Under MacsBug, I can see that my programs routines are being called (ie, I see the labels when I crawl the return addresses on the stack) but malloc() calls something unknown, which I suspect is library code of some sort. If it makes a difference, the problem occurs in a parsing routine (courtesy of yacc/lex from a UNIX machine) trying to apparently copy a string to somewhere useful. I'm using the ANSI-881 library with 68881 code generation turned on (non-FPU code in some files was twice the size!) and I'm using the console library, at least until I get the thing to run successfully. If anyone has experience with malloc() problems or suggestion as to where to bang my head into concrete, please let me know. It's very discouraging to have this much code compile but die on something as common as malloc. Ugh. -- |_ /| | Robert Minich | |\'o.O' | Oklahoma State University| There are no heroes -- |=(___)= | minich@a.cs.okstate.edu | We all wear gray hats. | U | - Ackphtth |
mm5l+@andrew.cmu.edu (Matthew Mashyna) (07/31/90)
>I'm trying to port Rayshade 3.0 to my Mac (SE/30) and am having >strange difficulties. I've managed to get all the code compiled OK with >minor alterations (the project file is ~700K and the final app ~160K) >but I am running into problems with malloc() Although I have given >plenty of memory to the partition (under the debugger and as a stand >alone app), malloc() goes off into deep thought and never exits. AAARRRRGGGG! This seems to be one of the biggest headaches with Think C 4.0. I've seen so many people have *alloc() work a few times then spit up blood. I went crazy over this at first. The cure ? Always include stdlib.h and stdio.h. You may also find that you need to include strings.h too. One thing I'd really like to see is better argument checking. It seems with Think C you get too little or too much. Of course if this doesn't fix your problem I take all that critisism (and bad spelling) back :-) ============================================================================= |Matt Mashyna | "That is the most obscene abomination of a song... | |mm5l@andrew.cmu.edu | that is dirt, that is filth, that is trash. What | |Carnegie Mellon | possessed you to write such a disgusting, degenerate | | Every day is | type song as this ? ... And I'm complementing you by | | Earth Day. | considering it a song." - a critic | =============================================================================
steve@bitstream.com (Steve Stein) (08/02/90)
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 <stdlib.h> 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.