malloc error

[afarah]

Under what condition will we see a segmentation fault in the malloc
library routine? Specifically, a failure in call to "chunk_allo c()"
from within malloc.

I have a multi-threaded c++ program that occasionally core-dumps in
"malloc" when running on Linux 2.4 (it always works fine on Solaris
5). The stack trace shows the final call to "chunk_allo c".

I would like to re-create this bug within a debugger. However, the
segmentation fault happens so infrequently that I think I need to have
a better idea of how a problem like this can arise before I can
re-create it.

Many thanks in advance for any ideas.

[Victor Bazarov]

afarah wrote:

Under what condition will we see a segmentation fault in the malloc
library routine? Specifically, a failure in call to "chunk_allo c()"
from within malloc.

I have a multi-threaded c++ program that occasionally core-dumps in
"malloc" when running on Linux 2.4 (it always works fine on Solaris
5). The stack trace shows the final call to "chunk_allo c".

I would like to re-create this bug within a debugger. However, the
segmentation fault happens so infrequently that I think I need to have
a better idea of how a problem like this can arise before I can
re-create it.

Many thanks in advance for any ideas.

Multi-threading is OT here simply because C++ program model is a single
process on a single CPU with all parts of the program executing in
a sequence. Intrinsics of C library are too, because they are very
compiler-specific. Differences between OSes are also beyond the scope
of this newsgroup. Perhaps you will find better help in a forum for
your compiler or OS. Try comp.os.linux.d evelopment.apps or gnu.g++.help.

In general a library routine fails when it gets invalid input, and there
is no invalid input for malloc, IIRC. Any number you pass in is going to
be interpreted as an unsigned integral value, and the system will either
allocate the requested amount, in which case a pointer to it is returned,
or fail to do so, in which case it will return a null pointer.

In most cases unexpected segmentation faults are due to memory corruption
that happened some time before the code that breaks is executed. You may
need some memory checking tools (like Purify) to see what's going wrong
with the program's memory. Of course, program's being multithreaded
doesn't really help...

Good luck!

Victor

[Nils O. Selåsdal]

afarah wrote:

Under what condition will we see a segmentation fault in the malloc
library routine? Specifically, a failure in call to "chunk_allo c()"
from within malloc. If there is a bug in the malloc library.

More common though, you have a nasty bug which does something very
bad, probably corrupting the heap,stack or otherwise invoke undefined
behavior.
I have a multi-threaded c++ program that occasionally core-dumps in
"malloc" when running on Linux 2.4 (it always works fine on Solaris
5). The stack trace shows the final call to "chunk_allo c".

I would like to re-create this bug within a debugger. However, the
segmentation fault happens so infrequently that I think I need to have
a better idea of how a problem like this can arise before I can
re-create it.

Get a hold of valgrind, and run your program in its memory checker tool.

[Ron Natalie]

afarah wrote:

Under what condition will we see a segmentation fault in the malloc
library routine? Specifically, a failure in call to "chunk_allo c()"
from within malloc.

To amplify on what Victor said. The most common problem with malloc()
and free() exploding is that on a previous allocation you did something
bad.

The most common ones are:

1. Freeing something not malloced, or freeing the same value twice.
2. (I vote for this one) Writing out of the bounds of a previous malloc.
Common malloc implementations put control information for the space
management intermixed with the allocations. Write a few bytes outside
of a malloc'd region is almost sure to corrupt malloc's internal data.

[Gianni Mariani]

afarah wrote:

Under what condition will we see a segmentation fault in the malloc
library routine? Specifically, a failure in call to "chunk_allo c()"
from within malloc.

I have a multi-threaded c++ program that occasionally core-dumps in
"malloc" when running on Linux 2.4 (it always works fine on Solaris
5). The stack trace shows the final call to "chunk_allo c".

I would like to re-create this bug within a debugger. However, the
segmentation fault happens so infrequently that I think I need to have
a better idea of how a problem like this can arise before I can
re-create it.

Many thanks in advance for any ideas.

It's an app bug.

Try running the app under valgrind with and set the environment variable
GLIBCXX_FORCE_N EW (or GLIBCPP_FORCE_N EW depending on version of GCC).

Or try runnung under efence.