doug@ponder.csci.unt.edu (Douglas A. Scott) (03/04/91)
I just finished recompiling the source for a large piece of software to be sure that it would work properly under 2.0. It is pure C code, no OOP stuff. When I try to run it I get: Smashed zone. Header size invalid Malloc corrupted entering malloc Now, this program ran under 1.0a, on Suns, Vaxen, etc., with no problems... so what's the deal? Is this really some coding problem that has *just* been revealed to me for the first time by cc 2.0 on the cube? :-o The program does do a lot of on-the-fly malloc'ing of space, but I have been very diligent in keeping it legal. Any ideas? BTW, it exits sig 6 after that, and gdb doesnt catch it before it quits. Thanks for any advice! -- ___________________________________________________________________________ Douglas Scott zardoz!doug%woof.columbia.edu
cpenrose@sdcc13.ucsd.edu (Christopher Penrose) (03/05/91)
In article <1991Mar4.025906.24602@solo.csci.unt.edu> doug@ponder.csci.unt.edu (Douglas A. Scott) writes: >I just finished recompiling the source for a large piece of software to be >sure that it would work properly under 2.0. It is pure C code, no OOP stuff. >When I try to run it I get: > >Smashed zone. Header size invalid >Malloc corrupted entering malloc You may get some mail from some people telling you that your own software is hosed and that NeXT's malloc() is not a problem. I have had problems with malloc() myself. In general, I have solved the problems by applying a minimum allocation size (8192 bytes) for *every* malloc() space allocation. People then accused me of having pointer indices that were out of bounds. These people think they are so clever. Even if I mailed them a copy of every pointer reference with its index these people would not be convinced. Gdb has shown me on several occasions that pointer values are often corrupted by non-related code. I have been recommended to use the new zone allocation classes; however, I have not had time to experiment with them yet. Research and application of these new (albeit NeXT specific) memory management classes may be worthwhile. Christopher Penrose jesus!penrose
scott@erick.gac.edu (Scott Hess) (03/05/91)
In article <17176@sdcc6.ucsd.edu> cpenrose@sdcc13.ucsd.edu (Christopher Penrose) writes: In article <1991Mar4.025906.24602@solo.csci.unt.edu> doug@ponder.csci.unt.edu (Douglas A. Scott) writes: >I just finished recompiling the source for a large piece of software to be >sure that it would work properly under 2.0. It is pure C code, no OOP stuff. >When I try to run it I get: > >Smashed zone. Header size invalid >Malloc corrupted entering malloc by non-related code. I have been recommended to use the new zone allocation classes; however, I have not had time to experiment with them yet. Research and application of these new (albeit NeXT specific) memory management classes may be worthwhile. Unfortunately, using the zone-specific stuff won't cure the problems, as the regular malloc is (I believe) implemented in terms of the zone memory allocation. I, too, had some stuff which broke under certain pre-release versions of 2.0, but worked fine under 1.0. I've also got some stuff which sort of works - it runs just fine, with nary a core file in sight, but the mallocation stuff claims stoutly that other stuff is being trashed. I'm not sure what to think . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad <I still speak for nobody> "Tried anarchy, once. Found it had too many constraints . . ." "I smoke the nose Lucifer . . . Bannana, banna."