Ticket #1031 (new bug)

Opened 12 years ago

Last modified 11 years ago

Free()ing of SymReg variables

Reported by: coke Owned by:
Priority: normal Milestone:
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:


From the  Original RT

On Mon, Aug 27, 2007 at 09:00:42AM -0700, Paul Cochrane wrote:

> In looking through some of the warnings that Coverity Prevent has
> thrown up one common thing has come up which I'd like some advice
> about. We are getting "leaked storage" errors often associated with
> variables declared as SymReg[1]. For example, in
> compilers/imcc/pbc.c, at line 1463, the variable 'r' is assigned and
> then goes out of scope a few lines afterwards. This Coverity picks up
> as being leaked storage. However, if I put C<mem_sys_free(r);> at the
> end of the relevant block, C<make test> fails. There are other
> instances as well compilers/imcc/imcparser.c:2964 (i.e.
> compilers/imcc/imcc.y:598) and compilers/imcc/imcparser.c:675,
> compilers/imcc/imcparser.c659 (this time with the variable 'r3').

There are definitely some memory leaks here. I've seen these in Valgrind reports for a while. My best explanation is that we stick these new pointers in memory somewhere, but don't free them appropriately.

I haven't been able to perform sufficient lifetime analysis to track down where they go and where to free them, yet. Patches welcome.

-- c

As a first step, it would be nice if someone with access to the Coverity reports could verify if this was still being reported as an issue.

Change History

Changed 11 years ago by jkeenan

  • component changed from none to core
Note: See TracTickets for help on using tickets.