ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: SuSE 9.0, Red Hat 9.0, Fedora core 1
*** glibc detected *** malloc() / free()/ double
I have made a small C program that make use of malloc and free this program works well on:
gcc version 3.3.1,
When I ported my program to
gcc version 4.0.1,
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.
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.
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).
Thanks for the tip. Diehard worked great on a buggy citrix client (ver 10.6) on ubuntu intrepid 8.10.
[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).
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.
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.
Well, dude. It's a very hard to find the solution,
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).
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.