Take the 2-minute tour ×

I get the following error when I run my program and it won't happen under gdb. How can I force glibc or ubuntu to dump core on abort? I tried "ulimit -c unlimited". But, this is not a seg fault and no luck. Also, I have too many memory errors in valgrind fixing all of them will take a lot of time.

Also, setting MALLOC_CHECK_ to 0 is not forcing program to exit. But, that's not a option for me.

* glibc detected ./main: free(): invalid next size (fast): 0x0000000000ae0560 **

Edit Anyway I found what is exactly causing this glibc corruption in valgrind. Just keeping it open to see if it's possible.

share|improve this question
You likely have heap corruption or "double free" or another problem with memory management - a kind of problem that you should address ASAP instead of patching. –  sharptooth Apr 26 '11 at 7:21
Duplicate of stackoverflow.com/questions/151268 btw ...? –  0xC0000022L Apr 26 '11 at 11:30
It's not a duplicate. By default glibc is aborting in my ubuntu. What I want is a coredump file when it aborts. –  user357689 Apr 26 '11 at 16:57
@user357689: your edit proves the point I made, does it not? ;) –  0xC0000022L Apr 26 '11 at 17:10

2 Answers 2

From glibc documentation:


Calling abort() usually produces a core dump (subject to ulimit -c setting).

share|improve this answer

Use Valgrind to diagnose and fix the problem. It will be quicker and straight to the point, since this indeed looks like a classic heap corruption.

There is likely a (Valgrind) package available for your distro, if you use a common one.

The only other method to create a core dump would be to attach GDB to the process before it happens. But that still doesn't get you closer to the solution of what causes the problem. Valgrind is the superior approach.

share|improve this answer
I said I was using valgrind and that I had lot of errors(2k+) in my initial question. It is this library not my code. So, I want to start with some critical issues and go my way down and hence wanted coredump out of gdb. –  user357689 Apr 26 '11 at 16:55
@user357689: errors in Valgrind do not always have to be errors in the first place (that's what ignore files exist for) and secondly one root cause can often lead to hundreds of lines with errors. Still, only the root cause is relevant. When fixed the next run will often have considerably less errors. Note: the important part (thus emphasized) was that the error(s) should be fixed, not just diagnosed. Any time invested in learning Valgrind and its output won't be wasted. –  0xC0000022L Apr 26 '11 at 17:01

Your Answer


