bug-mailutils
[Top][All Lists]
Advanced

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

Re: mailutils (rf822 parser)


From: Alain Magloire
Subject: Re: mailutils (rf822 parser)
Date: Mon, 2 Apr 2001 00:31:36 -0400 (EDT)

> 

> I'm changing the return values, and checking all over the place
> for malloc failures. Turns out to be a major PITA. C sucks sometimes.

8-)
Indeed, it would be easier to throw and unwind the stack.

You can do it by cleverly using setjmp()/longjmp().

IIRC, this is how exceptions use to work in the old GCC releases.
You could unwind the stack by keeping the jump_buf and throw().

> And I'm not sure how to test it. Will electric fence detect unfreed
> memory on program exit?

No.

> Any other more portable suggestions? I

To check memory leaks?
There are different libraries, I sometime use dmalloc, it provides
post-fence checking, memory leaks checking etc ...
http://dmalloc.com/
http://sourceforge.net/projects/dmalloc/

The only thing annoying about dmalloc is that it does not give
a backtrace of where the memory leak occured.  We have a usefull
little program inhouse that uses gcc __builtin_return_address() internall
functions to get a backtrace.
 
> think I can stub malloc by using GNU ld magic, might look into that.
> 

What are you trying to accomplish?
parse822 leaks only when things failed 8-).
I can write a very dirty C implementation of try {} catch() throw();
If that can make things easier.  If it is important to walk the stack
It is possible to make the throw() unwind.

It may seem a little heavy hand at first 8-)  But can probably be
reuse in other parts.

> We've purify at work, it might do something useful.
> 

It's a shame purify does not run on QNX/QRTP.

--
alain




reply via email to

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