r18295 - gnucash/trunk/src - Fix more valgrind problems
Phil Longstaff
plongstaff at rogers.com
Tue Sep 8 19:29:35 EDT 2009
On September 8, 2009 04:43:48 pm Christian Stimming wrote:
> Am Dienstag, 8. September 2009 16:30 schrieb Phil Longstaff:
> > Yes. The purpose of this call was for scm so that the returned string
> > wouldn't be leaked. If swig could wrap a call and free the result, that
> > would be an even better solution.
>
> We have plenty of functions throughout gnc-qof and the engine which return
> newly allocated strings that need to be free'd by the caller. I was pretty
> sure swig can handle that situation correctly. At least that's my vague
> memory of when I was working with this more intensively.
>
> Your patch r18295 and also r18294 unfortunately seem to introduce yet more
> possibilities for error, both of which have already been mentioned. I would
> strongly prefer to have swig free the result by itself, or rather keep
> living with the memory leak until someone has found out how to tweak swig
> so that it does that. In this case, the reason "valgrind has pointed out
> this to be a problem" IMHO isn't enough of a reason to introduce this
> blatantly obvious other sources of error, only to make the valgrind
> warnings silent. Please solve this in a different way. Thanks a lot!
OK. Swig can handle the situation correctly if it is told in the correct way
to do so. To do that, you need a '%newobject XXX' line before it comes across
the declaration of function XXX. I'll remove the new functions and update the
.i files appropriately.
Phil
More information about the gnucash-devel
mailing list