"double free or corruption" - how to solve this?

"double free or corruption" - how to solve this?

[Shriramana Sharma]

One of my programs, which was working quite well till now, suddenly
gives me the error:

*** glibc detected *** double free or corruption (top): 0x0808a338 ***
Aborted

It is a pure C program compiled with GCC 4.02 -- I do not understand
why it does not work suddenly. Please tell me what the above error can
be.

Thanks.

Re: "double free or corruption" - how to solve this?

[wwp]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Hello Shriramana,


On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma" <samjnaa@gmail.com> wrote:

> One of my programs, which was working quite well till now, suddenly
> gives me the error:
> 
> *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> Aborted
> 
> It is a pure C program compiled with GCC 4.02 -- I do not understand
> why it does not work suddenly. Please tell me what the above error can
> be.

Would be nice to run it from gdb, in order to get the backtrace when it
crashes. This should help you understand where and why :).


Regards,

-- 
wwp

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: "double free or corruption" - how to solve this?

[Steve Graegert]

On 5/12/06, wwp <subscript@free.fr> wrote:
> Hello Shriramana,
>
>
> On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma" <samjnaa@gmail.com> wrote:
>
> > One of my programs, which was working quite well till now, suddenly
> > gives me the error:
> >
> > *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> > Aborted
> >
> > It is a pure C program compiled with GCC 4.02 -- I do not understand
> > why it does not work suddenly. Please tell me what the above error can
> > be.
>
> Would be nice to run it from gdb, in order to get the backtrace when it
> crashes. This should help you understand where and why :).

Additionally, you can try valgrind, which reports typical programming
errors like calling free() twice on the same object.

	\Steve

Re: "double free or corruption" - how to solve this?

[Nate Jenkins]

>> Hello Shriramana,
>>
>>
>> On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma" 
>> <samjnaa@gmail.com> wrote:
>>
>> > One of my programs, which was working quite well till now, suddenly
>> > gives me the error:
>> >
>> > *** glibc detected *** double free or corruption (top): 0x0808a338 ***
>> > Aborted
>> >
>> > It is a pure C program compiled with GCC 4.02 -- I do not understand
>> > why it does not work suddenly. Please tell me what the above error can
>> > be.
>>
>> Would be nice to run it from gdb, in order to get the backtrace when it
>> crashes. This should help you understand where and why :).
>
> Additionally, you can try valgrind, which reports typical programming
> errors like calling free() twice on the same object.
>
> \Steve
> -

Steve,

I just saw that utility the other day.  It looks interesting.  How do you 
typically use it?  or grindcall-grindval?  Do you know of a good tutorial 
you could point me/us to?

TIA,

N8â„¢


-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "double free or corruption" - how to solve this?

[Steve Graegert]

On 5/12/06, Nate Jenkins <nate@uniwest.com> wrote:
>
> >> Hello Shriramana,
> >>
> >>
> >> On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma"
> >> <samjnaa@gmail.com> wrote:
> >>
> >> > One of my programs, which was working quite well till now, suddenly
> >> > gives me the error:
> >> >
> >> > *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> >> > Aborted
> >> >
> >> > It is a pure C program compiled with GCC 4.02 -- I do not understand
> >> > why it does not work suddenly. Please tell me what the above error can
> >> > be.
> >>
> >> Would be nice to run it from gdb, in order to get the backtrace when it
> >> crashes. This should help you understand where and why :).
> >
> > Additionally, you can try valgrind, which reports typical programming
> > errors like calling free() twice on the same object.
> >
> > \Steve
> > -
>
> Steve,
>
> I just saw that utility the other day.  It looks interesting.  How do you
> typically use it?  or grindcall-grindval?  Do you know of a good tutorial
> you could point me/us to?

Nate,

The easiest way to use valgrind is to pass it the "apparently faulty"
program including all arguments using the --tool switch:

graegerts@kenji:~/vmware/haiku> valgrind --tool=memcheck ls -la

Afterwards a summary is printed:

==11048== Memcheck, a memory error detector for x86-linux.
==11048== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==11048== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==11048== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==11048== For more details, rerun with: -v
==11048==

[lengthy file listing omitted]

==11048==
==11048== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1)
==11048== malloc/free: in use at exit: 14901 bytes in 21 blocks.
==11048== malloc/free: 446 allocs, 425 frees, 48474 bytes allocated.
==11048== For a detailed leak analysis,  rerun with: --leak-check=yes
==11048== For counts of detected errors, rerun with: -v
graegerts@kenji:~/vmware/haiku>

By entering "valgrind" in the console a list of available tools is
listed, all of them obeying the --help switch:

% valgrind
valgrind: Missing --tool option
Available tools:
        helgrind
        addrcheck
        cachegrind
        memcheck
        callgrind
        corecheck
        lackey
        none
        massif
% valgrind --tool=memcheck --help

The valgrind homepage (http://valgrind.org) is a good starting point
for documentation and description of related concepts.  Hope that was
helpful.

Bye

	\Steve

Re: "double free or corruption" - how to solve this?

[Nate Jenkins]

>> >> Hello Shriramana,
>> >>
>> >>
>> >> On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma"
>> >> <samjnaa@gmail.com> wrote:
>> >>
>> >> > One of my programs, which was working quite well till now, suddenly
>> >> > gives me the error:
>> >> >
>> >> > *** glibc detected *** double free or corruption (top): 0x0808a338 
>> >> > ***
>> >> > Aborted
>> >> >
>> >> > It is a pure C program compiled with GCC 4.02 -- I do not understand
>> >> > why it does not work suddenly. Please tell me what the above error 
>> >> > can
>> >> > be.
>> >>
>> >> Would be nice to run it from gdb, in order to get the backtrace when 
>> >> it
>> >> crashes. This should help you understand where and why :).
>> >
>> > Additionally, you can try valgrind, which reports typical programming
>> > errors like calling free() twice on the same object.
>> >
>> > \Steve
>> > -
>>
>> Steve,
>>
>> I just saw that utility the other day.  It looks interesting.  How do you
>> typically use it?  or grindcall-grindval?  Do you know of a good tutorial
>> you could point me/us to?
>
> Nate,
>
> The easiest way to use valgrind is to pass it the "apparently faulty"
> program including all arguments using the --tool switch:
>
> graegerts@kenji:~/vmware/haiku> valgrind --tool=memcheck ls -la
>
> Afterwards a summary is printed:
>
> ==11048== Memcheck, a memory error detector for x86-linux.
> ==11048== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
> ==11048== Using valgrind-2.2.0, a program supervision framework for 
> x86-linux.
> ==11048== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
> ==11048== For more details, rerun with: -v
> ==11048==
>
> [lengthy file listing omitted]
>
> ==11048==
> ==11048== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1)
> ==11048== malloc/free: in use at exit: 14901 bytes in 21 blocks.
> ==11048== malloc/free: 446 allocs, 425 frees, 48474 bytes allocated.
> ==11048== For a detailed leak analysis,  rerun with: --leak-check=yes
> ==11048== For counts of detected errors, rerun with: -v
> graegerts@kenji:~/vmware/haiku>
>
> By entering "valgrind" in the console a list of available tools is
> listed, all of them obeying the --help switch:
>
> % valgrind
> valgrind: Missing --tool option
> Available tools:
>        helgrind
>        addrcheck
>        cachegrind
>        memcheck
>        callgrind
>        corecheck
>        lackey
>        none
>        massif
> % valgrind --tool=memcheck --help
>
> The valgrind homepage (http://valgrind.org) is a good starting point
> for documentation and description of related concepts.  Hope that was
> helpful.
>
> Bye
>
> \Steve
> -

Very helpful.  And speedy.  :)

Thanks.  That is what I assumed it might be like.  I will have to do some 
learning about that tool and others like it.  I am looking down the road, 
knowing that I have a memory leak to track down soon in a project I have 
been asked to fix.

Thanks again,

Nate

RE: "double free or corruption" - how to solve this?

[james-lists]

Hi,


Try linking your program with electric fence. It may already be installed it
comes on most distros now. Add -lefence when linking. It should help you pin
point the problem very quickly when used with a debugger like gdb.

	James

> -----Original Message-----
> From: linux-c-programming-owner@vger.kernel.org [mailto:linux-c-
> programming-owner@vger.kernel.org] On Behalf Of Shriramana Sharma
> Sent: 12 May 2006 09:11
> To: linux-c-programming@vger.kernel.org
> Subject: "double free or corruption" - how to solve this?
> 
> One of my programs, which was working quite well till now, suddenly
> gives me the error:
> 
> *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> Aborted
> 
> It is a pure C program compiled with GCC 4.02 -- I do not understand
> why it does not work suddenly. Please tell me what the above error can
> be.
> 
> Thanks.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-
> programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "double free or corruption" - how to solve this?

[Steve Graegert]

On 5/12/06, Shriramana Sharma <samjnaa@gmail.com> wrote:
> One of my programs, which was working quite well till now, suddenly
> gives me the error:
>
> *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> Aborted
>
> It is a pure C program compiled with GCC 4.02 -- I do not understand
> why it does not work suddenly. Please tell me what the above error can
> be.

Shriramana,

From earlier posts at SLE I suppose you're running SuSE 10 (please
correct me if I am wrong) which uses a glibc version with an
integrated memory checker that can be turned of by setting

export MALLOC_CHECK_=0

If the program is simple you will not have to use dbg in order to
locate the offending code if any.  A combination of electric fence (as
James suggested) and valgrind should do it.  OTOH, if you're using
some libs and/or have switched to a different glibc version recently
you may have some lib mess.  Anyway, try to figure out what's wrong
with using the tools mentioned here and post the code if possible and
give gdb a try.

Bye

	\Steve

AW: "double free or corruption" - how to solve this?

[Jedenastik, Günther]

>Hello Shriramana,


>On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma" <samjnaa@gmail.com> >wrote:

>> One of my programs, which was working quite well till now, suddenly
>> gives me the error:
>> 
>> *** glibc detected *** double free or corruption (top): 0x0808a338 ***
>> Aborted
>> 
>> It is a pure C program compiled with GCC 4.02 -- I do not understand
>> why it does not work suddenly. Please tell me what the above error can
>> be.

>Would be nice to run it from gdb, in order to get the backtrace when it
>crashes. This should help you understand where and why :).


>Regards,

>-- 
>wwp

I have a similar problem, but i don't know how gdb can help with this?
I tried with gdb (btw: I have one process forked (and a few threads) and I think this process creates the problem) but I only get the problem during exit handlers (e.g. SIGINT)

To get back to my question: how can I trace the problem with gdb, if I have forked processes and threads?

Cause it seems, that glibc only prints the line "*** glibc detected *** double free or corruption" and then continues
It doesn't send a SIGABORT or something else, so why should gdb "know" something was wrong? And how could I trace back (using "bt") if I have the problem, but don't know where it occures (cause glibc just prints and continues, not?)
I think the only "simple" way is using electric fence (?)

I'll try this next Monday

But some internal explanations what "*** glibc detected ***" does (not why it occures, but internally happens if it occures), if anyone knows, would be great

Thx and regards

Re: "double free or corruption" - how to solve this?

[Steve Graegert]

On 5/12/06, Jedenastik, Günther <guenther.jedenastik@maxolution.at> wrote:
>
> >Hello Shriramana,
>
>
> >On Fri, 12 May 2006 13:41:12 +0530 "Shriramana Sharma" <samjnaa@gmail.com> >wrote:
>
> >> One of my programs, which was working quite well till now, suddenly
> >> gives me the error:
> >>
> >> *** glibc detected *** double free or corruption (top): 0x0808a338 ***
> >> Aborted
> >>
> >> It is a pure C program compiled with GCC 4.02 -- I do not understand
> >> why it does not work suddenly. Please tell me what the above error can
> >> be.
>
> >Would be nice to run it from gdb, in order to get the backtrace when it
> >crashes. This should help you understand where and why :).
>
>
> >Regards,
>
> >--
> >wwp
>
> I have a similar problem, but i don't know how gdb can help with this?

Indeed, in this case gdb is more helpful when operating on core dumps.

> I tried with gdb (btw: I have one process forked (and a few threads) and I think this process creates the problem) but I only get the problem during exit handlers (e.g. SIGINT)
>

gdb has excellent thread debugging facilities; you should have no
problem to switch between threads (see "thread", "info threads" and
"threads apply" commands) and attaching to child processes.

> To get back to my question: how can I trace the problem with gdb, if I have forked processes and threads?
>
> Cause it seems, that glibc only prints the line "*** glibc detected *** double free or corruption" and then continues

By default, the offending program is killed by emitting SIGABRT.  A
core dump is generated only if the system is configured to do so (see
ulimit -c and use a reasonably large value).  Nevertheless, the
program you want to get a core dump from should intercept SIGABRT and
if you can't set the limits beforehand, you might be able to attach
with gdb, use setrlimit to eliminate the coredump restriction and then
send an ABRT.

> It doesn't send a SIGABORT or something else, so why should gdb "know" something was wrong? And how could I trace back (using "bt") if I have the problem, but don't know where it occures (cause glibc just prints and continues, not?)

No, it actually should not.  See if the environment variable
MALLOC_CHECK_ is not to 0 (zero).

> But some internal explanations what "*** glibc detected ***" does (not why it occures, but internally happens if it occures), if anyone knows, would be great

This output is the result of some sanity checks of glibc that can be
configured by setting MALLOC_CHECK_ to values between 1 and 3, while 0
turns checks off, thus not printing a message and not killing the
program.

Bye

	\Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html