Hi!!,

I have made a small C program that make use of malloc and free this program works well on:

linux 2.4.21-99-default,
gcc version 3.3.1,
glibc 2.3.2.,
p4, 512MB,

When I ported my program to

linux 2.6.11-1.1369_FC4,
gcc version 4.0.1,
glibc 2.3.5,
P2, 128MB

I am getting a lot of error something like
*** glibc detected *** free(): invalid next size (normal),
***glibc detected *** malloc() : memory corruption,
*** glibc detected *** double free or corruption (!prev)

Eveb after searching/googling on this I could not find perfect answer.

[#]. http://www.linuxquestions.org/questi...by=&sortorder=

Here no body has answered for fedora everybody is talking about slackware.

OR, I might have missed some links

Can anybody of you please tell me,
what is the reason for this? and
how can I get rid of this?

Any help will be appreciated

Thanks & Regards

If you post the source you are trying to compile ( or at least the part of the code that causes the problem ) then it might be easier to help you. If this is a compiler error, then chances are that it is a result of something in your code that is not standard C, ANSI C, or C99 compliant, and that the new default for the compiler is to check more rigorously.

If this is a runtime error, then it is likely the case that your code has always had memory leaks in it (ie you free memory that you didn't alloc, or forget to free mem that you alloc) and that they are only apparent now that the newer gcc or glibc has applied some stricter controls.

Good luck.

asgeirss: Thanks for the response.

I have switched to glibc2.3.2,
So now everything is ok.

But yeah you are right, my program really had some problem related to freeing the memory, which I have removed now and hopefully it will work fine on glibc2.3.5.
but I have not tested yet.

Thanks

When you get warnings like "glibc detected malloc()/free()/double", they indicate that the heap has been corrupted. One work around is to use DieHard, which replaces your memory allocator with one that is unaffected by most of these errors (www.diehard-software.org). DieHard is unaffected by double frees, and also provides substantial protection against dangling pointer errors and heap buffer overflows (which also lead to similar warnings).

Regards,
-- Emery

Emery,

Thanks for the tip. Diehard worked great on a buggy citrix client (ver 10.6) on ubuntu intrepid 8.10.

Kannan


[QUOTE=emeryberger;2738799]When you get warnings like "glibc detected malloc()/free()/double", they indicate that the heap has been corrupted. One work around is to use DieHard, which replaces your memory allocator with one that is unaffected by most of these errors
DieHard is unaffected by double frees, and also provides substantial protection against dangling pointer errors and heap buffer overflows (which also lead to similar warnings).

Regards,

This is dangerous. This could be quite bad.

When you get error messages which complain that the heap is corrupted, then glibc is actually doing you a favor.

Because it could very well be that all your calls to malloc(), calloc(), realloc(), and free() are correct, but that you are attempting somewhere in your program to write beyond the end or prior to the beginning of an allocated area, thus stomping on the data that the memory allocation software uses for bookkeeping.

The danger here is that you could be stomping on some of your own data as well. One part of your software, the part that contains the bug, could be stomping on the data used by another part, and you could get reasonable-looking but wrong data in ways that you don't discover for years. This possibility is quite reasonable, and dangerous.

If you switch to a version of glibc that doesn't complain, you are walking away from the problem.

If you remove the calls to free(), you are walking away from the problem. They are the canary in the coal mine. If the canary dies, you don't worry about the poor canary, you see it as a sign that something is seriously wrong.

You would do well to put back the calls to free(), all of them, switch back to a version of glibc that complains, and fix the real problem.

I have seen this kind of problem in source code where strings are allocated on the function stack and then passed to sub-functions that try to free or realloc these blocks of memory. Sometimes it's extremely difficult to hunt these bugs down.
Valgrind is a good tool to get some statistics about your memory leaks.
Diehard is an interesting tool, I didn't heard of it before.

linux

Hi Kannan,

Glad to hear it. Was this a problem that you could reliably reproduce? If so, I would love to hear more details.

Thanks,
-- Emery

Emery can you please tell me or someone step by step how to install this?

how do i set that environment variable? where does that go?

sorry all new to this

thanks

You need to set the LD_PRELOAD variable. The information is in the src/README file included with the DieHard distribution.

Build the shared library with "make". You can either link in the
resulting shared object (libdiehard.so), or use DieHard by
setting the LD_PRELOAD environment variable, as in:

or (for sh),

You can replace "export LD_PRELOAD" to directly run your application,
as in

Best,
-- Emery

Well, dude. It's a very hard to find the solution, because the compile runs without any warnings. See this piece of code:

aloc = (float**)(malloc(m*sizeof(float*)));
for(i=0;i<m;i++)
aloc[i] = (float*)(malloc((n+1)*sizeof(float*)));
for(i=0; i<m; i++)for(j=0; j<=n+1; j++)aloc[i][j]=0.;

if((auxOf= (float) malloc (m*sizeof ( float ) ))==NULL)printf("Falha na alocacao de memo.\n");


It compiles without any warning, and when you run the program, this message appears:
*** glibc detected *** ./main: malloc(): memory corruption: 0x089b60c8 ***

The mistake was done in the line:
for(i=0; i<m; i++)for(j=0; j<=n+1; j++)aloc[i][j]=0.;
The correct spell:
for(i=0; i<m; i++)for(j=0; j<n+1; j++)aloc[i][j]=0.;

So, it's a very dangerous problem, very difficult to detect.

Warning. Dead thread resurrected.

By now he either found a solution or gave up.

Please look at the dates on previous posts before replying.

You are free to answer anyway, no matter how long ago the last post was made. Sometimes that will even be a good idea.

But don't expect whoever originally asked the question to still be interested (Unless it was one of the few times I asked a very hard question and never got a solid answer. For all of those, I'm still interested even years later. But the question in this thread is easy to search for and covered very well in many other threads, and the OP in this thread hasn't posted at LQ in many years).

Good point.

Footnote: Since this is a very common scenario, and since RAM is frankly quite plentiful now, many programming languages now offer their own heap-protection primitives which operate invisibly to your program. (But they only work for disposing of the memory that you allocated using their mechanisms ... the most common use-case.) The idea is simple, and also easy to improvise in your own libraries/apps should you need to do so, so I thought I'd briefly relate how it works.

(1) The memory-allocation function allocates, say, "eight bytes more" than the amount you request, using the standard library mechanism. It then puts an "eyecatcher," say four bytes long, at the beginning and at the end of the block. It then hands you the address "plus four bytes" so you never see the eyecatcher. That trailing-eyecatcher is just beyond your reach, such that your application will never know about it i-f "it is a good boy that never misbehaves."

(2) It's also tremendously useful if the allocation routine also sets the entire memory-block that it gives you to "known zeros," using an appropriate library-routine. It greatly improves the application, IMHO, for all dynamic memory to have predictable, NULL, content, so that any program errors are far more likely to be reproducible.

(3) The memory-free routine checks for the presence of the eyecatchers. (If the leading eyecatcher isn't there, it's a bogus address. If the trailing eyecatcher isn't there, the block has been "scribbled" and therefore the entire memory-allocation mechanism is probably toast, so "let's die right now.") The memory-free routine then changes the two eyecatchers to a different value used for "a freed memory-block." It releases the entire memory-block including both now-altered eyecatchers using the standard library mechanism.

The advantage of this simple system is that it is fast, adding no significant amount of overhead, and it also greatly improves the chances of detecting memory-scribbles without the use of an external debugger. In other words, it's suitable to put into production code and leave it in place, and that's exactly what I do.