help-gplusplus
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: double free or corruption - it works on older machine


From: Paul Pluzhnikov
Subject: Re: double free or corruption - it works on older machine
Date: Wed, 16 Aug 2006 22:20:34 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux)

alan.larkin@gmail.com writes:

>> > I get a "*** glibc detected *** double free or corruption (!prev):
>> > 0x00002aaabc610420 ***" error which IMHO is a scurrilous lie ... 

It is almost certainly *not* a lie, but a bug which you simply have
not (yet) observed on the older machine.

>> > I dont
>> > see anything wrong with the code which has been working for a long
>> > time.

That proves *nothing*. Last week I fixed a bug which was present
for the last 5 years, in the code that executes in our nighly build
100s of times, on 6 different architectures.

This bug never ever showed up, until we started a "special" build,
which reliably failed on just 1 of the 6 machines.

>> Also, does it compile
>> without warnings and does it follow guidelines for safe, modern C++?

Doble-free is extremely unlikely to be flagged as a warning by
any compiler.

> So I can launch a java process ($java -XrunMYLIB ...) and attach gdb to
> the MYLIB stuff!? Any chance you know how?

Sure. Just make MYLIB code sleep() for some time, and attach gdb
to the running Java process (you can find its PID with "ps").

Use "gdb /path/to/java [pid]" ...

You can also let java process dump core, and analyze the core in gdb
(post-mortem debugging).

Unfortunately there are situations where finding double-free is
extremely difficult. This is why specialized tools, such as Valgrind,
Purify and Insure++ exist.

You can try Valgrind, but I haven't had success with it on JNI programs.
However, other people have used it successfully (do read VG FAQ).

Purify supports JNI (AFAICT from IBMs marketing materials).

> Anyway, code.

I can't see anything wrong with the code you've posted.
Note that enabling/disabling some code often hides heap corruption
bugs, and that doesn't at all mean the bug is in the disabled code.

Disabling the code often simply makes the bug hide better -- it
is still present, but no longer observed (without the specialized
tools).

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]