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?
LVL 1
shiversAsked:
Who is Participating?
 
alien_life_formConnect With a Mentor Commented:
Greetings.

A ttol that may be useful in these circumstances is ElectricFence (ships with at least RedHat) You have to (at least relink). Efence overrides the malloc strategy by stuffing each allocation between two protected memory pages. That way, when the prog oversteps, it segfaults right away, so you get a core dump on the bad instruction (rather than somewhere in the blu yonder). I'm not sure Efence helps  if your problem is a bad free, though.

Other popular, homegrown strategies involve overriding malloc and free:

--file mymalloc.h--

#ifndef _MYMALLOC_H_
#define _MYMALLOC_H_
#ifdef DEBUG
#define malloc(x) (mymalloc((x)))
#define free(x)   (myfree((x)))
#endif
#endif

You then implement mymalloc and myfree (which call on the real malloc and free) so as to keep track of what you malloc and of what you free, put sentinel data at the beginning and and of blocks, etc.
You thenneed to insert an
#include mymalloc.h

in all the modules you wnat to check, recompile (-DDEBUG) and relink.

You could probably couple the second solutions with Efence.

HTH & cheers,
   alf
0
 
jlevieCommented:
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.
0
 
rbrCommented:
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.
0
 
940961slCommented:
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 :-)
0
 
shiversAuthor Commented:
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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.