Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jan 2002 12:17:13 +0100
From:      Robert Suetterlin <robert@mpe.mpg.de>
To:        freebsd-questions@freebsd.org
Cc:        freebsd-hackers@freebsd.org
Subject:   HOW to debug memory corruption efficiently?
Message-ID:  <20020130111713.GA25203@robert2.mpe-garching.mpg.de>

next in thread | raw e-mail | index | archive | help
Hello everyone!

	I have a problem using some third party C++ library. After
returning from a seemingly innocent function call my stack frame gets
destroyed step by step --- and maybe other parts of memory as well.
	Unfortunately I'm neither proficient in C++ nor efficient in
debugging, so I stumble around the problem rather blindfolded.  Once
I blamed the compiler, systemlibraries and operating system, I knew
I needed some help.  The problem appeared on a linux system, but I
guess the techniques I might need will be the same under Linux,
FreeBSD or any un*x.

I checked the program execution using gdb and found that in the cleanup
code after the function call (this is under Linux, so I will not present
the assembler, as I guess clean up will be different under freebsd)
something strange happens.  When displaying the backtrace with gdb, the
debugger suddenly complains:
6       card = new DAQ::SISO::Grabber(1);
(gdb) bt
#0  DAQ::SISO::Slave::Slave (this=0xbffff65b) at Slave.cc:6
#1  0x0804a352 in main () at test.cc:10
#2  0x400df65f in __libc_start_main () from /lib/libc.so.6
(gdb) n
10     card->LoadFramegrabberDesign( const_cast<char *>(name), 26, 52 );
(gdb) bt
#0  DAQ::SISO::Slave::Slave (this=0xbffff65b) at Slave.cc:10
#1  0x0804a352 in main () at test.cc:10
#2  0x400df65f in __libc_start_main () from /lib/libc.so.6
Cannot access memory at address 0xbf080506

I stepped (s) and single stepped (si) over ther card = new ... command.
The 'Cannot access memory' appears four single steps after finish
returns from the Constructor.  So not while within the Constructor or
any function called from there.  The assembler command after which the strange
message appears seems to restore the basepointer (i386).
	Later during program execution (everytime after a method call using
card->method(); my stack frame gets corrupted slowly or the message
'Cannot access memory' changes to complain about different adresses.

I guess that somewhere within the Constructor or some function called
therein my stack and registers stored there get corrupted due to a
memory leak, freak pointer, etc.  Is there an efficient way to find out
which part of the program is responsible for the corruption.  I.e. is
there an efficient way to fix the blame either to my code or the third
party libraries :)?
	Or is there another likely cause of this problem, which has
nothing to do with freak pointers or the libraries, but with using C++
wrong.  I compiled using -Wall and got no warnings.


Sincerely, Ronbert S.


-- 
Robert Suetterlin (robert@mpe.mpg.de)
phone: (+49)89 / 30000-3546   fax: (+49)89 / 30000-3950

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020130111713.GA25203>