Control never returns from malloc()

[Michael McGarry]

Hi,

I have some code that never returns from a call to malloc(), does
anyone have any ideas? There is plenty of free memory on the system.
This is running in Linux kernel 2.4.20. The code has been run on
several different Linux machines. This same code runs without any
problems on Mac OS X.

Here is the GDB log:
(gdb) step
1160 hungarian_schedule =
malloc(SCHEDULER_NUM_SLOT*simParams.NUM_LAMBDAS*sizeof(int));
(gdb) print 180*simParams.NUM_LAMBDAS*sizeof(int)
$7 = 1440
(gdb) step

Program received signal SIGINT, Interrupt.
0x42074d44 in malloc_consolidate () from /lib/tls/libc.so.6
(gdb)

I hit CTRL-C to stop the code and that is when it displays that
interrupted in malloc_consolidate().

Any help would be greatly appreciated.

Thanks,

Michael

 

[Ben Pfaff]

I have some code that never returns from a call to malloc(), does
anyone have any ideas? There is plenty of free memory on the system.

There is probably a bug in your code. For example, you might be
writing beyond the end of an allocated block. Try a memory
debugger, e.g. valgrind on x86/Linux.

 

[Default User]

Hi,

I have some code that never returns from a call to malloc(),

Code which you keep a secret from those who might be able to debug it.

does anyone have any ideas?

Show us the code?



Brian

 

[michael.mcgarry]

GDB shows that the execution stays in malloc(), could it still be
something related to my writing beyond the end of an allocated block?
Why would the code work on Mac OS X?

 

[David Lindauer]

GDB shows that the execution stays in malloc(), could it still be
something related to my writing beyond the end of an allocated block?
Why would the code work on Mac OS X?

yes... depending on the malloc/free implementation this can happen.
Writing beyond the end of a malloc'd block results in undefined behavior,
which can even differ between different compilers on the same OS. On the
MAC os if you are indeed doing this the specific undefined behavior is
that it appears to work, although that doesn't mean that it won't cause
other problems down the road. With GCC if you are doing this the
undefined behavior is that it throws a signal...

David

 

[Walter Roberson]

:GDB shows that the execution stays in malloc(), could it still be
:something related to my writing beyond the end of an allocated block?
:Why would the code work on Mac OS X?

Because in Mac OS X, you stomp on something different; or
you stomp on the same place but it doesn't happen to have
anything important there because the libraries are different
sizes/locations; or perhaps the Mac OS X allocator chains its
free blocks differently.


For tough problems like this, I highly recommend the product
named Purify, the original company for which has been bought
twice and so is now officially called "IBM Rationale Purify".

It's definitely not a product you need every day, but if you
have stray pointers, or unrealized uninitialized variables
[including from structure copies], or if you are wandering
off the end of an array, then Purify can really save your
fundament. It is not cheap or free, but if you are doing
production coding then it pays for itself in very little time
indeed. There's a free trial period for it.

 

[CBFalconer]

I have some code that never returns from a call to malloc(), does
anyone have any ideas? There is plenty of free memory on the system.
This is running in Linux kernel 2.4.20. The code has been run on
several different Linux machines. This same code runs without any
problems on Mac OS X.

Sure, line 1233 in foobar.c is writing over the malloc internal
data. Cut your code down to a minimum that exhibits the problem,
not over 100 to 200 lines, compilable, and publish it here if you
haven't found the problem yourself. We are not genies released
from the bottle.

 

[Randy Howard]

GDB shows that the execution stays in malloc(), could it still be
something related to my writing beyond the end of an allocated block?

It could be almost anything. It's hard for anyone to guess without
seeing code. Normally, whittling the code down to a small compilable
program that reproduces the behavior is helpful, but in this case,
I suspect (just by intuition if nothing else) that the more you take
away, the harder it will be to reproduce. Have you turned up all
the warning levels as high as you can?

Do you check the return code from malloc() and friends everywhere
they are used? Do you check for NULL pointers before you follow
them? Etc.

Why would the code work on Mac OS X?

Undefined behavior means it could work fine on 10 other platforms
and still fail on your current one. It doesn't have to make sense,
unfortunately.

 

[Servé La]

Hi,

I have some code that never returns from a call to malloc(), does
anyone have any ideas? There is plenty of free memory on the system.
This is running in Linux kernel 2.4.20. The code has been run on
several different Linux machines. This same code runs without any
problems on Mac OS X.

Here is the GDB log:
(gdb) step
1160 hungarian_schedule =
malloc(SCHEDULER_NUM_SLOT*simParams.NUM_LAMBDAS*sizeof(int));
(gdb) print 180*simParams.NUM_LAMBDAS*sizeof(int)
$7 = 1440
(gdb) step

How big is
SCHEDULER_NUM_SLOT*simParams.NUM_LAMBDAS*sizeof(int)
?

 

[Richard Bos]

How big is
SCHEDULER_NUM_SLOT*simParams.NUM_LAMBDAS*sizeof(int)

If SCHEDULER_NUM_SLOT is 180, it's apparently 1440. And if so, that
should pose no problems - at least not of the kind as seen by Mr.
McGarry.

Richard

 

[Michael McGarry]

Thanks, all your comments are very helpful. I guess I need to track
down where my pointers are going beyond the memory allocated. Are there
any free tools that are good for aiding in this endeavor?

Thanks,

Michael