#1031: Free()ing of SymReg variables
--------------------+-------------------------------------------------------
Reporter: coke | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: none | Version:
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
--------------------+-------------------------------------------------------
From the [http://rt.perl.org/rt3/Ticket/Display.html?id=44993 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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1031>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
