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

Re: memory debugging and C++ (program keeps crashing)



On Sat, Sep 28, 2002 at 08:10:27PM -0700, Osamu Aoki wrote:
>      * njamd

reports heaps of memory leaks even before my program starts.

>      * valgrind

requires unstable.

>      * dmalloc

had problems with dmalloc.h, also C++ support doesn't look like it is
compiled in the default installation (see other message)

>      * electric-fence

Didn't even run my program before crashing (see prior message).

>      * memprof

Good profiler, good X based GUI, good leak detector (no leaks detected
though).

Doesn't detect what ever is causing my program to crash though...

>      * memwatch

Couldn't find this in Debian.

apt-cache show memwatch
W: Unable to locate package memwatch

>      * mpatrol

Nothing reported. I wonder if it was working, or
if it really did find no problems.

>      * leaktracer

Good leak detector (no leaks detected though).

Again doesn't detect what is causing my program to crash.

>      * libgc6

Couldn't work out how to use it; linking against it has no apparent
affect (or maybe this just means no leaks detected?)

>      * Insure++ from Parasoft. (non-free, commercial for fee)

URL?

> URL: http://www.cs.colorado.edu/homes/zorn/public_html/MallocDebug.html

A short description of my problem:

I have a C++ program that uses a library that uses the C bindings of ORBIT.

My program regularly (and randomly) crashes, each time in a different
way:

* CORBA Exception IDL:omg.org/CORBA/COMM_FAILURE:1.0
(note: I don't believe a communication failure actually occured;
another client still talks to the same server on localhost fine
without any errors).

* segmentation fault in about 2 different places.

I have tried looking up gdb traces, and all I find is
instances of Orbit code which I know to be correct.

I have tried removing code until it stops crashing. At one stage I
noticed it kept crashing on the last statement in the sequence A,B,A.
So B looked very suspicious. In fact B does call (indirectly) a
complicated function for copying a list. I removed the call, now when it
crashes, it crashes (but only sometimes) on the first A.

(another curious fact is that another program which uses the same
library and calls the same functions works fine).

argghh!

I suspect some sort of memory allocation error, but can't think
of what would cause this problem. I was very careful not to free
any memory still in use for instance (although I can't guarantee
that there wasn't anything I missed).

Any ideas?

Maybe I am on the wrong track completely?

Thanks in advance.

(If anyone is really bored and wants to help debug this, I can
provide GPL source code...)
-- 
Brian May <bam@snoopy.apana.org.au>



Reply to: