SIGSEGV in malloc()

[Joakim Hove]

Hello,

in my application I have a typedefed struct:

typedef struct {
double d1;
int i1;
/* I have simplified the object here. */
} data_ptr_type;


I allocate storage for such object many times in my application, and
at some point in time (repeatedly at the same spot, but seemingly
random to me), the application fails with a SIGSEGV at:

data_ptr_type * data = malloc(sizeof *data);

To me it seems quite illogical that the malloc implementation should
be able to die with a SIGSEGV(?) - either it should return a pointer
to freshly allocated storage, or if that is not possible it should
return NULL. Can this be a sign of a bug in the malloc()
implementation - I know that sounds unlikely but??

My system is:
RedHat Enterprise Linux
gcc-3.4.6
64 bit computer, but comiled with -m32 switch.

Any suggestions?

Regards Joakim

 

[Richard Heathfield]

Joakim Hove said:

I allocate storage for such object many times in my application, and
at some point in time (repeatedly at the same spot, but seemingly
random to me), the application fails with a SIGSEGV at:

data_ptr_type * data = malloc(sizeof *data);

To me it seems quite illogical that the malloc implementation should
be able to die with a SIGSEGV(?) -

It's impossible to say for sure without seeing the code, but it's my
guess that you've probably done one of these three things:

1) free(p); ..... later, you used this indeterminate pointer value - OR
2) free(p); ..... later, free(p); - OR
3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }

Like I said, I'm just guessing really (because I can't see the code),
but any of the above could explain why your malloc arena is stuffed.

 

[Richard Tobin]

To me it seems quite illogical that the malloc implementation should
be able to die with a SIGSEGV(?) -

[/QUOTE]

It's impossible to say for sure without seeing the code, but it's my
guess that you've probably done one of these three things:

1) free(p); ..... later, you used this indeterminate pointer value - OR
2) free(p); ..... later, free(p); - OR
3) p = malloc(sizeof *p); if(p != NULL) { modify(&p) somehow; free(p); }

Or (4) you've "run off the end" of some malloc()ed memory, perhaps
modfying the 5th element of a 4 element array. Any of these things
may mess up malloc()'s data structures, causing an obscure error some
time later when you call malloc() or free().

-- Richard

 

[Joakim Hove]

Or (4) you've "run off the end" of some malloc()ed memory, perhaps
modfying the 5th element of a 4 element array.

Thank you for the suggestion, it indeed turned out to be an error
along the these lines.

Any of these things
may mess up malloc()'s data structures, causing an obscure error some
time later when you call malloc() or free().

I guess what kind of baffled me (somewhat naively ??) was that it was
so easy to interfere with malloc()'s internal state. Anyway, now I
know.

Thank's again.

Joakim

 

[Richard Tobin]

I guess what kind of baffled me (somewhat naively ??) was that it was
so easy to interfere with malloc()'s internal state. Anyway, now I
know.

There are many very effective tools that can help in tracking down
this kind of error. Valgrind for example has probably saved thousands
of person-years of tedious debugging.

-- Richard

 

[Old Wolf]

Thank you for the suggestion, it indeed turned out to be an error
along the these lines.

I guess what kind of baffled me (somewhat naively ??) was that it was
so easy to interfere with malloc()'s internal state. Anyway, now I
know.

Some people are extremely sensitive about the speed and
memory requirements of their programs that use malloc,
preferring that it use as few bytes and picoseconds of
overhead as possible, even if that means a fragile structure.

Accordingly, compilers tend to make their malloc as fast as
possible. However, some compilers offer a switch to use a
more robust allocation scheme during debugging (or even
in the release version, if the allocation is not a bottleneck);
check your compiler documentation.