{"issue":{"state":"open","pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"milestone":null,"user":{"avatar_url":"https://secure.gravatar.com/avatar/d1588981e0248aaa0174906c99df180e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"d1588981e0248aaa0174906c99df180e","url":"https://api.github.com/users/petdance","login":"petdance","id":41100},"updated_at":"2011-11-01T04:24:55Z","assignee":{"avatar_url":"https://secure.gravatar.com/avatar/d1588981e0248aaa0174906c99df180e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"d1588981e0248aaa0174906c99df180e","url":"https://api.github.com/users/petdance","login":"petdance","id":41100},"labels":[],"closed_at":null,"comments":0,"url":"https://api.github.com/repos/petdance/scratch/issues/116","body":"From the [http://rt.perl.org/rt3/Ticket/Display.html?id=44993  Original RT]\r\n\r\nOn Mon, Aug 27, 2007 at 09:00:42AM -0700, Paul Cochrane wrote:\r\n\r\n{{{\r\n> In looking through some of the warnings that Coverity Prevent has\r\n> thrown up one common thing has come up which I'd like some advice\r\n> about. We are getting \"leaked storage\" errors often associated with\r\n> variables declared as SymReg[1]. For example, in\r\n> compilers/imcc/pbc.c, at line 1463, the variable 'r' is assigned and\r\n> then goes out of scope a few lines afterwards. This Coverity picks up\r\n> as being leaked storage. However, if I put C<mem_sys_free(r);> at the\r\n> end of the relevant block, C<make test> fails. There are other\r\n> instances as well compilers/imcc/imcparser.c:2964 (i.e.\r\n> compilers/imcc/imcc.y:598) and compilers/imcc/imcparser.c:675,\r\n> compilers/imcc/imcparser.c659 (this time with the variable 'r3').\r\n\r\nThere 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.\r\n\r\nI haven't been able to perform sufficient lifetime analysis to track down where they go and where to free them, yet. Patches welcome.\r\n\r\n-- c\r\n}}}\r\n\r\nAs 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.\r\n","html_url":"https://github.com/petdance/scratch/issues/116","title":"Free()ing of SymReg variables","number":116,"id":2104961,"created_at":"2011-11-01T04:24:55Z"},"action":"opened"}