By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,444 Members | 3,110 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,444 IT Pros & Developers. It's quick & easy.

using "purify" to check memory leaks

P: n/a
Hi,

My C code (running on Soalris Unix) has some "segmentation fault"
that I wish to use purify to do it. I poked around the web, and found
some information about adding some lines in a Makefile file to use
purify. However, my code is a rather simple single-source C program,
and I didn't write a Makefile for it.

I'm wondering if anybody can tell me which commands are to be
entered at the Unix prompt to use purify. And, I don't know if "purify"
is installed on our system or not (I tried "which purify" to find it,
but it wasn't found). Could someone also give me some help of its
possible whereabouts and how to interface it with my program?

Thanks in advance.

-Ed

Nov 14 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
In article <11**********************@g47g2000cwa.googlegroups .com>,
<ey**@ece.cornell.edu> wrote:
My C code (running on Soalris Unix) has some "segmentation fault"
that I wish to use purify to do it. I poked around the web, and found
some information about adding some lines in a Makefile file to use
purify. However, my code is a rather simple single-source C program,
and I didn't write a Makefile for it.


Makefiles and purify (and Solaris) are usually considered off-topic
for comp.lang.c .
:I'm wondering if anybody can tell me which commands are to be
:entered at the Unix prompt to use purify. And, I don't know if "purify"
:is installed on our system or not (I tried "which purify" to find it,
:but it wasn't found). Could someone also give me some help of its
:possible whereabouts and how to interface it with my program?

When it is installed, you would usually build the executable
normally, such as compiling "eyh5.c" to produce the executable "eyh5",
and once the executable was built, you would normally invoke the
"purify" command naming the executable to be examined. purify would
then instrument the executable and produce a new executable with
the same name but with an additional suffix of ".pure"; in this example,

purify eyh5 to produce eyh5.pure

One would then run the .pure executable (e.g., ./eyh5.pure ).
I have no recollection of where purify would typically be installed
for Solaris, but try looking for /usr/pure/ and /opt/pure/
--
"I want to make sure [a user] can't get through ... an online
experience without hitting a Microsoft ad"
-- Steve Ballmer [Microsoft Chief Executive]
Nov 14 '05 #2

P: n/a
Walter Roberson wrote:

[snip]

When it is installed, you would usually build the executable
normally, such as compiling "eyh5.c" to produce the executable "eyh5",
and once the executable was built, you would normally invoke the
"purify" command naming the executable to be examined. purify would
then instrument the executable and produce a new executable with
the same name but with an additional suffix of ".pure"; in this example,

purify eyh5 to produce eyh5.pure

One would then run the .pure executable (e.g., ./eyh5.pure ).


Your above description about running purify is *horribly* wrong. Please
don't advice, when you don't know the things, especially off-topic issues.

Krishanu
Nov 14 '05 #3

P: n/a
I would suggest you to use Electric Fence, mpr or checker to handle
problems of Memory Leakage.

ELECTRIC FENCE
**********************
Electric Fence does not find memory leaks, but help to isolate buffer
overruns. As linux, like every modern operating system provides
hardware memory protection to isolate programs from each other.

Electric Fence replaces C libraries malloc() function with a version
that allocates the requested memory and usually allocates a section of
memory immideately after this, which the process is not allowed to
access!
When the process tries to access the memory block pass the allocated
one, kernel traps and halts the process with a segmentation fault! Most
of us might have struggled with this error while working with pointer.

This way Electric Fence manages to get the program killed when it
passes the allocated space.

libefence.a is the library for Electric Fence!

compile the code against Electric Fence library...

$ gcc -ggdb -Wall -o memleak memleak.c -lefence

$ gdb memleak
GDB .....
.....
....
....
(gdb) run
Starting program: /home/achindrab/memleak
Electric Fence... Copyright ...
1: 12345
Program received signal SIGSEGV, segmentation fault.
....
....
(gdb) where
....
..... in main() at memleak.c:18
....
(gdb)

So now we know the error is at line number 18!!!
CHECKER
**************
Checker adds extra code to a program to help find overflows and memory
leaks. Instead of compiling a program with gcc, we can use checkergcc
and the resulting program will debug itself.

The compilation string will be the same:

$ checkergcc -o memleak memleak.c

On executing a program compiled with checkergcc, a long report of
errors is printed ...

The first part of the output tells that we wrote to the part of heap
(memory allocated by malloc()) that was out of all9ocated region. It
tells exactly where the block was allocated - line 11, and which
function caused - strcpy() at line 12.

When we write too many bytes to the local variable, checker gives a
warning that we are writing off the end of stack.

Documentation states, that checker cannot find writes past end of local
buffers, but writes past end of stacks. Thus if more variables have
been allocated after local, checker would not find any problem.

MPR
******
mpr is another tool to play with memory leak problems.

The approach that mpr takes to find the memory leak problems is to map
each malloc( ) with a corresponding free( ) function call. This is a
similar approach, that we take, most often, to detect a memory leak. To
find memory corruption mpr includes a replacement malloc( ) library
from GNU project that includes some support for memory allocation
debugging, which is enabled by calling the mcheck( ) function! We need
to link the application against libmpr.a using command line option:
-lmpr, mcheck( ) will be activated automatically.
Using mcheck( )
~~~~~~~~~~~~
Unlike Electric Fence, mpr's malloc ( ) function adds sequesnce of
bytes, before and after the allocated memory. free( ) looks for those
signatures, and cals abort( ) if they are disturbed...

Running a mpr linked program in gdb shows exactly which region has been
corrupted, but does not pinpoints where the corruption occured. It is
up to the programmer to identify that.

When a program(mpr linked) is run in gdb, it aborts with a signal
abort. on running command 'where', gdb tells the error at free( )
function call, which indicates the problem region.

Over runs on Global variables and local variables, still remains
undetected, can any one help me in that....
A detail explaination on using Debuggers in C is available at:

http://groups-beta.google.com/group/giGABits/

Nov 14 '05 #4

P: n/a
Bhatnagar Achindra wrote:

I would suggest you to use Electric Fence, mpr or checker to handle
problems of Memory Leakage.

.... snip ...

I suggest you keep this sort of off-topic junk out of c.l.c.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Nov 14 '05 #5

P: n/a
I don't think, that is an off topic jump, Ed had faced a segmentation
fault in his program, to his knowledge, he can solve that with purify,
I just added a few debugging libraries to solve such problems.

Nov 14 '05 #6

P: n/a
Bhatnagar Achindra wrote:

I don't think, that is an off topic jump, Ed had faced a segmentation
fault in his program, to his knowledge, he can solve that with purify,
I just added a few debugging libraries to solve such problems.


c.l.c deals with the portable C language as defined in the C
standard. Not with system dependent whatevers. Whatever 'purify'
is, it is not a part of the language. See the newusers link below.

You should also quote enough of any article to which you reply to
establish proper context. Either avoid the faulty google usenet
interface by getting a newsreader, or put in the effort to use it
correctly.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Nov 14 '05 #7

P: n/a
In article <42***********************@news.sunsite.dk>,
Krishanu Debnath <kr******@cal.interrasystems.com> wrote:
Walter Roberson wrote:
purify eyh5 to produce eyh5.pure One would then run the .pure executable (e.g., ./eyh5.pure ).


Your above description about running purify is *horribly* wrong. Please
don't advice, when you don't know the things, especially off-topic issues.


I hadn't realized that I could sustain the same hallucination for
9 straight years.
$ cat testpure.c
#include <stdio.h>
int main(void) {
char junk[] = "deliberate mistake";
free(junk);
}
$ cc -o testpure testpure.c
$ purify -windows=no testpure
Purify 4.5 IRIX6, Copyright (C) 1992-2000 Rational Software Corp. All rights reserved.
..... Processing "/usr/lib32/libc.so.1"
..... Processing "testpure"
$ ./testpure.pure
[...]
**** Purify instrumented ./testpure.pure (pid 17229802) ****
FNH: Freeing non heap memory:
* This is occurring while in:
_free [malloc.c:1090]
_stub [*unknown src*]
main [testpure.c:4]
__start [crt1text.s:176]
__start [crt1text.s:159]
* Attempting to free block at 0x7fff2ed0 on the stack.
* Address 0x7fff2ed0 is 0 bytes above stack pointer in function main.
* Note: Some 'free's permit freeing such memory, but this is not portable.
To suppress this error, add 'suppress fnh *' to your .purify file.
[...]
--
Studies show that the average reader ignores 106% of all statistics
they see in .signatures.
Nov 14 '05 #8

P: n/a
Walter Roberson wrote:
In article <42***********************@news.sunsite.dk>,
Krishanu Debnath <kr******@cal.interrasystems.com> wrote:
Walter Roberson wrote:

purify eyh5 to produce eyh5.pure One would then run the .pure executable (e.g., ./eyh5.pure ).


Your above description about running purify is *horribly* wrong. Please
don't advice, when you don't know the things, especially off-topic issues.


I hadn't realized that I could sustain the same hallucination for
9 straight years.
$ cat testpure.c
#include <stdio.h>
int main(void) {
char junk[] = "deliberate mistake";
free(junk);
}
$ cc -o testpure testpure.c
$ purify -windows=no testpure
Purify 4.5 IRIX6, Copyright (C) 1992-2000 Rational Software Corp. All rights reserved.
.... Processing "/usr/lib32/libc.so.1"


Hey, that doesn't work on my solaris system, I wonder why?

temp(526)$ cat testpure.c
(slightly modified from your testpure.c)
#include <stdlib.h>
int main(void)
{
char junk[] = "foo";
free(junk);
return 0;
}
temp(527)$ cc -o testpure testpure.c
temp(528)$ purify -windows=no testpure
Sorry, 'testpure' is an unknown compiler.
Usage: purify <compiler> foo.o ...

The reason people don't like off topic advice is because this
isn't the right place and errors won't be caught. And tools
such as purify and how they work in whatever particular version a
user has installed (or whether they are normally installed) on
windows or linux or solaris or irix isn't on topic here. Kindly
redirecting people to the correct group is a better approach,
perhaps with an occasional OT pointer on how to get started is
better than giving explicit (and possibly wrong) answers to OT
questions. All IMHO of course...

-David

Nov 14 '05 #9

P: n/a
On 26 May 2005 17:54:48 GMT, in comp.lang.c ,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:
In article <42***********************@news.sunsite.dk>,
Krishanu Debnath <kr******@cal.interrasystems.com> wrote:

Your above description about running purify is *horribly* wrong. Please
don't advice, when you don't know the things, especially off-topic issues.


I hadn't realized that I could sustain the same hallucination for
9 straight years.


The hallucination is that how purify works on irix is in any way
indicative of how it works on solaris or linux or wherever.

*dont* post offtopic advice, its often wrong, and generally
unverifiable.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #10

P: n/a
Walter Roberson wrote:
In article <42***********************@news.sunsite.dk>,
Krishanu Debnath <kr******@cal.interrasystems.com> wrote:
Walter Roberson wrote:


purify eyh5 to produce eyh5.pure
One would then run the .pure executable (e.g., ./eyh5.pure ).

Your above description about running purify is *horribly* wrong. Please
don't advice, when you don't know the things, especially off-topic issues.

I hadn't realized that I could sustain the same hallucination for
9 straight years.


As others already pointed out that usage of purify is different in different
systems. But my language was not polite in my previous post. I apology for that.

Krishanu
Nov 14 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.