How to find memory leaks -- linux 64 bit
Divick
can somebody suggest me what memory leak detection tool exist
for 64 bit Linux platforms and which is better. I am facing problem
while running a 64 bit application. GDB is not of much use as it shows
the error at different places in code everytime. I have no clue what am
I doing wrong and where. Now I have no idea that how shall I narrow
down the problem.
Any ideas/ suggestion?
Thanks,
Divick
"Nils O. Selåsdal"
(though I don't know if it copes with 64 bit yet..)
Divick
64 bit architecture.
Any other tool that you know of?
Thanks,
Divick
Paul Pluzhnikov
> Valgrind does not work on 64 bit machines.
Oh yes it does, since version 3.0 (current is 3.0.1, I believe).
> Any other tool that you know of?
Insure++ also supports Linux for amd64.
For leak detection, any number of debug malloc libraries will also
suffice (it's not clear from your message whether your problem
really is a leak, or something else altogether).
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
Divick
on the Valgrind homepage, it says that it works for 64bit
AMD architecture. But nothing about Intel64. So I will have my verdict
until I try it on Intel64 bit. I remember I tried compiling Valgrind a
few months back and it didn't compile on Intel-64 bit. ( don't remember
the exact version of valgrind that I was trying to compile).
Regarding the problem that I am facing, actually I am getting some
strange errors while running my application on 64 bit platform with
gdb. To be precise it gets a SIGTRAP and then it is unable to do a
backtrace. See the link below (original problem posted on gdb mailing
list).
http://sourceware.org/ml/gdb/2005-09/msg00138.html
Now the only problem could be of access through a bad pointer or memory
leak (as far as I understand, correct me if I am wrong). For this
purpose I need some opensource tool which can run on SuSE9.1 with Intel
64 bit machine and help me debug the application. Since gdb alone is
not of much use, I am stuck.
Thanks,
Divick
Paul Pluzhnikov
> on the Valgrind homepage, it says that it works for 64bit
> AMD architecture. But nothing about Intel64.
Intel EM64T is almost identical to AMD64 from user space, except
for SSE3 vs 3dNow! instructions. Valgrind 3.x works quite well
on either.
> I remember I tried compiling Valgrind a
> few months back and it didn't compile on Intel-64 bit. ( don't remember
> the exact version of valgrind that I was trying to compile).
VG 3.0 was announced on August 4, 2005.
> Regarding the problem that I am facing, actually I am getting some
> strange errors while running my application on 64 bit platform with
> gdb. To be precise it gets a SIGTRAP and then it is unable to do a
> backtrace. See the link below (original problem posted on gdb mailing
> list).
>
> http://sourceware.org/ml/gdb/2005-09/msg00138.html
>
> Now the only problem could be of access through a bad pointer or memory
> leak (as far as I understand, correct me if I am wrong).
It doesn't look like either. It is almost definitely *not* the
result of a memory leak. It actually looks like stack corruption.
Unfortunately, VG is rather weak in detecting stack corruption. You
may have better luck with gcc-4.x -fmudflap, or with Insure++.
> For this purpose I need some opensource tool
Since you have access to SGI Altix, surely you can afford to buy
a commercial app if it will help you find the problem?
Kasper Dupont
>
> Hi Paul,
> on the Valgrind homepage, it says that it works for 64bit
> AMD architecture. But nothing about Intel64. So I will have my verdict
> until I try it on Intel64 bit.
What architecture? Intel produces CPUs of more than one 64 bit
architecture. They produce Itanium CPUs, but they also produce
AMD64 clones.
--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.
Divick
1, revision 5. 1.4 GHz. Has anyone tried compiling Valgrind on this
processor/SuSE Linux
>>Since you have access to SGI Altix, surely you can afford to buy
>>a commercial app if it will help you find the problem?
I am working for SGI and I don't own the Altix system ( actually a
Prism system -- new generation high performance Scalable Graphics
system). And to get a commercial tool, I must evaluate its merits
against others to suggest it to the higher management. :)
>> You may have better luck with gcc-4.x -fmudflap, or with Insure++.
I downloaded gcc -4 and when I run it it gives strange errors. It
catches a signal and then crashes (don't remember the exact problem
since it was worked on by a colleague of mine and he was unable to run
it).
Is Insure++ free / or does it have trial version for Intel 64 bit ?
Thanks for the reply,
Divick
Divick
but while doing a ./configure it says precisely ...
configure: error Unsupported host Architecture.
Thanks,
Divick
Mikko Rauhala
Righto, IA64 (Itanium) is not supported. Most people think of the
AMD64 compatible processors when you talk about 64-bit Intels, so
you may want to be more precise asking next time.
--
Mikko Rauhala - m...@iki.fi - <URL:http://www.iki.fi/mjr/>
Transhumanist - WTA member - <URL:http://www.transhumanism.org/>
Singularitarian - SIAI supporter - <URL:http://www.singinst.org/>
Paul Pluzhnikov
> Well to be precise, the exact processor is Intel Itanium2 IA 64
Ah... Sorry, I actually knew that SGI Altix uses Itanic, but somehow
this didn't register, and I was still assuming you are using the
more popular Linux for x86_64.
> Has anyone tried compiling Valgrind on this processor/SuSE Linux
This processor is not currently supported by VG, and (due to its
extremely low popularity, high price, and complicted instruction set)
is unlikely to ever be supported.
> I downloaded gcc -4 and when I run it it gives strange errors.
There is also a set of bounds-checker patches for gcc-3.x series:
http://sourceforge.net/projects/boundschecking/
Perhaps you'll have better luck there (but this for C only, AFACT).
> Is Insure++ free / or does it have trial version for Intel 64 bit ?
Insure++ is not free. There was a beta version available for
Linux/ia64, but it never made it into production (due to almost
complete lack of customer demand).
If your app is "plain C", you may have better luck with CCured:
http://manju.cs.berkeley.edu/ccured/
Can your software run on Linux/x86? Plenty of tools are available
for that platform.
Oterwise, you may try your luck with Reasoning:
http://www.reasoning.com/solutions/reliability_inspection.html
or with Coverity:
http://www.coverity.com/products/index.html
Ni@m
Paul Pluzhnikov
> try http://valgrind.org/
Perhaps you should read more of the thread before replying?