LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 08-02-2005, 04:28 AM   #1
RohanShrivastav
Member
 
Registered: Sep 2004
Distribution: SuSE 9.0, Red Hat 9.0, Fedora core 1
Posts: 70

Rep: Reputation: 15
*** glibc detected *** malloc() / free()/ double


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
 
Old 08-02-2005, 04:23 PM   #2
asgeirss
Member
 
Registered: Aug 2003
Location: Vancouver, Canada
Distribution: RH, SL
Posts: 37

Rep: Reputation: 15
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.
 
Old 08-02-2005, 11:33 PM   #3
RohanShrivastav
Member
 
Registered: Sep 2004
Distribution: SuSE 9.0, Red Hat 9.0, Fedora core 1
Posts: 70

Original Poster
Rep: Reputation: 15
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
 
Old 05-06-2007, 06:53 PM   #4
emeryberger
LQ Newbie
 
Registered: May 2007
Posts: 4

Rep: Reputation: 0
Try DieHard

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
 
Old 02-20-2009, 12:49 AM   #5
wskannan
LQ Newbie
 
Registered: Feb 2009
Posts: 1

Rep: Reputation: 0
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,
 
Old 02-20-2009, 05:20 AM   #6
wje_lq
Member
 
Registered: Sep 2007
Location: Mariposa
Distribution: Debian lenny, Slackware 12
Posts: 808

Rep: Reputation: 178Reputation: 178
Quote:
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.
 
Old 02-23-2009, 11:30 AM   #7
gergely89
Member
 
Registered: Feb 2009
Posts: 100

Rep: Reputation: 21
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

Last edited by gergely89; 02-27-2009 at 10:51 PM.
 
Old 02-26-2009, 05:10 PM   #8
emeryberger
LQ Newbie
 
Registered: May 2007
Posts: 4

Rep: Reputation: 0
Quote:
Originally Posted by wskannan View Post
Emery,

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

Kannan

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
 
Old 03-21-2009, 12:58 AM   #9
s3lekta
LQ Newbie
 
Registered: Mar 2009
Posts: 1

Rep: Reputation: 0
Quote:
Originally Posted by emeryberger View Post
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
 
Old 03-24-2009, 12:37 PM   #10
emeryberger
LQ Newbie
 
Registered: May 2007
Posts: 4

Rep: Reputation: 0
Using DieHard

Quote:
Originally Posted by s3lekta View Post
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:

Code:
        setenv LD_PRELOAD /path/to/diehard/libdiehard.so
or (for sh),

Code:
LD_PRELOAD=/path/to/diehard/libdiehard.so; export LD_PRELOAD
You can replace "export LD_PRELOAD" to directly run your application,
as in

Code:
        LD_PRELOAD=/path/to/diehard/libdiehard.so myapp
Best,
-- Emery
 
Old 10-01-2012, 01:40 AM   #11
louis.augusto
LQ Newbie
 
Registered: Oct 2012
Posts: 1

Rep: Reputation: Disabled
I did a mistake and this message was shown

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.
 
Old 10-01-2012, 07:35 AM   #12
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,064

Rep: Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106Reputation: 1106
Warning. Dead thread resurrected.

Quote:
Originally Posted by louis.augusto View Post
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).

Last edited by johnsfine; 10-01-2012 at 07:42 AM.
 
Old 10-01-2012, 10:08 AM   #13
sundialsvcs
Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 5,330

Rep: Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100Reputation: 1100
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.
 
  


Reply

Tags
corruption, free, heap, malloc


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
FC3 glibc detected *** double free or corruption: josedragone Fedora 5 09-17-2009 10:16 PM
*** glibc detected *** double free or corruption (!prev): 0x082c1120 *** eXor Slackware 6 04-11-2008 08:47 AM
OpenOffice.org *** glibc detected *** free(): invalid pointer: 0x41481c94 *** Artanicus Linux - Software 2 02-19-2005 07:04 PM
Open Office user install error: *** glibc detected *** double free or corruption: 0xb r_jensen11 Linux - General 6 01-16-2005 06:08 AM
malloc/free in C h/w Programming 12 02-26-2004 01:13 PM


All times are GMT -5. The time now is 01:01 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration