gnupic: Re: [gnupic] gpasm memory leaks
Subject:
Re: [gnupic] gpasm memory leaks
From:
"David Barnett" ####@####.####
Date:
1 Jun 2007 18:44:08 +0100
Message-Id: <017801c7a473$cf81e7e0$0301a8c0@barnett2>
Another status update: I have several changes to submit. I separated them
into 3 patches to make it less confusing to review and accept/reject
changes. There were 3 groups of changes so far.
A few comments on each, in order of complexity:
* leaks1.patch -- the 2 small oversights. 1 call to free() added for each
* leaks3.patch -- free some strings when the parser finishes with them.
I'm not actually sure why they need to be allocated in the first place,
since they're only used as a selector in one function call and the parser
should be able to pass string literals instead (maybe it's in case the lexer
rules change?).
* leaks2a.patch -- the reorganization/push_symbol_table()-related changes.
There are 3 pointers that I changed to be statically allocated and removed
the memory leak (archive_tbl, definition_tbl, symbol_index), and one subtle
leak fixed in the 3rd chunk (no malloc before the call). The other changes
are preparation for those changes and several to come. For the preparation
changes, the only real change to logic is that the call to calloc has been
split into a malloc or static allocation outside push_s_t() and a memset
inside. Next I plan to change the symbol table stacks (state.stBuiltin,
etc.) to be mostly statically allocated (as members of the global "state"
struct). There are some complications in that some of the stacks will still
be pointers to others, but still I think static allocation should be enough.
Notice that all of the extra malloc's in the last patch are just moved out
of push_symbol_table() and commented. It looks like valgrind treats them
differently now even though they're still leaks. Only a few memory leaks
were fixed, but there shouldn't be any new leaks.
Also, these changes affect several gputils tools, but for now I'm focusing
on gpasm.
The changes passed regression tests as far as I understood, but it's still
quite possible I'm wrecking things =), so I'd encourage someone to try to
verify the changes before applying them to CVS.
David Barnett
----- Original Message -----
From: "David Barnett" ####@####.####
To: ####@####.####
Sent: Thursday, May 31, 2007 5:32 PM
Subject: Re: [gnupic] gpasm memory leaks
>A status update on the memory leaks for those interested: I've fixed a few
>and rearranged a few of them. Two of them were just careless mistakes, but
>several will take some serious rearranging...
> <snip>
>
> David Barnett
>
> ----- Original Message -----
> From: "David Barnett" ####@####.####
> To: ####@####.####
> Sent: Tuesday, May 29, 2007 3:32 PM
> Subject: [gnupic] gpasm memory leaks
>
>
> I noticed some suspicious allocation code in gpasm, so I checked it with
> valgrind. It seems to report several memory leaks in various places.
> I'll look into them further as I have time. Did anyone already notice
> these? I didn't see any bugs about memory leaks in the bug
> tracker...should I post some?
>
> David Barnett
[Content type application/octet-stream not shown. Download]
[Content type application/octet-stream not shown. Download]
[Content type application/octet-stream not shown. Download]
