HTTP/1.1 -1 Read error in cache disk data: SuccessContent-Type: text/tab-separated-values; charset="utf-8" Last-Modified: Sat, 22 Jan 2022 02:17:56 GMT Content-length: 1613 Connection: Close Proxy-Connection: Close X-Cache: HIT from web1.osuosl.org Server: ProxyTrack 0.5 (HTTrack 3.49.2) id summary reporter owner description type status priority milestone component version severity resolution keywords cc lang patch platform 1031 Free()ing of SymReg variables coke "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 at the > end of the relevant block, C 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. " bug new normal core medium arch">Search: