shivers
asked on
crashes on malloc() and free()
I'm writing quite a big program, and there's a rather irritating bug in it - it intermittently crashes and dumps the core (sig 11 - segmentation fault) on calls to malloc() and free().
Where this happens is vaguely reproducable - but not enough to be able to track down why.
The way I see it, the problem is one of two things: either a bug in the compiler (v. unlikely), or some part of my program is writing over some memory map table that malloc/free use to operate (not sure really - I don;t know how they work internally).
Anyone got any ideas? I think I need a debugging tool to track _every_ memory write and report those which write to areas other than my variables / allocated chunks - is there such a tool?
Where this happens is vaguely reproducable - but not enough to be able to track down why.
The way I see it, the problem is one of two things: either a bug in the compiler (v. unlikely), or some part of my program is writing over some memory map table that malloc/free use to operate (not sure really - I don;t know how they work internally).
Anyone got any ideas? I think I need a debugging tool to track _every_ memory write and report those which write to areas other than my variables / allocated chunks - is there such a tool?
It's most likely an errant pointer somewhere in the code that's overwriting all or part of a malloc'd region (writing past the end of a malloc'd block will do it). On a commercial Unix like Solaris, Irx, etc. there are lots of options for run-time bounds checkers (like Rational Purify, and others). There don't seem to be too many for Linux, Insure++ is one that I've found (http://www.parasoft.com) and there may well be others.
I don't think that you will be able to overwrite the memory map of the alloc/free funtion. More likely is that some pointers where the alloc/free is not correct in your programm. In general a code file is created on a segmentation fault. Compile and link your code with the debug option and use any debugger to analyze the core file to get more info. If you want you can send the code to rbr@tip-informatik.at.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I had a problem just like that writing a program in WINNT. I couldn't trace the problem but it had to do something with malloc and free. At the end, I found out that (at least for WINNT) there are 2 memory lib's : one for single thread programs and 1 for multithread programs. Using the second lib solved my problem. I don't know if this is the same in linux? Or perhaps an option to tell the compiler your using multiple threads (if you're using them of course :-)
ASKER
Lovely - I used electric fence and found my bug withing minutes - it's a gem of a utility!
It turned out it was a simple and stupid mistake - mallocing 1 byte less than I needed for certain things - causing weird screw ups later.
Thanx
It turned out it was a simple and stupid mistake - mallocing 1 byte less than I needed for certain things - causing weird screw ups later.
Thanx