Re: Memory leak in bison-generated code

[Jean Delvare]

Hi Joel,

On Fri, 6 Feb 2009 21:01:39 -0500 (EST), Joel E. Denny wrote:
> On Fri, 6 Feb 2009, Jean Delvare wrote:
> 
> > Valgrind tells me that there's a memory leak in libsensors [1], in code
> > which is generated by flex/bison:
> 
> > As this seemed to be the same problem as documented in this changelog
> > entry:
> > 
> > 2006-11-10  Joel E. Denny  <address@hidden>
> > 
> >     Fix memory leaks in scanners generated by at least Flex 2.5.9 and
> >     later.  Reported by Paul Eggert in
> 
> We generate Bison's own internal scanner/parser using Flex/Bison.  This 
> ChangeLog entry is for a fix for a memory leak in that internal scanner.  
> It does not affect memory leaks in a scanner or parser that you may 
> generate using Flex/Bison.

Thanks for the clarification. I had totally missed the fact that bison
was itself using flex internally. This caused me to misinterpret the
above changelog entry.

> > I upgraded to bison 2.4.1. Alas, the memory leak is still there, and as
> > a matter of fact I don't see any call to yylex_destroy() in the
> > generated code. If I do call sensors_yylex_destroy() manually then the
> > memory leak goes away.
> 
> > So I am wondering: does it mean that I did something wrong in my code,
> > which causes bison to not generate the call, or does it mean that the
> > leak is not completely fixed yet?
> 
> It's not up to Bison to generate this call.  You must write the call just 
> as we did for Bison's internal scanner.  Keep in mind that Flex generates 
> your scanner, so see the Flex manual for more details.

I have fixed my library code to call yylex_destroy() as appropriate. In
fact this is what I had done originally, but then I found the
above-mentioned bison changelog entry and thought that it was somehow up
to bison to free that memory, and I feared that upgrading to bison 2.4
would possibly double-free it if I did it myself. Now I understand that
I was wrong and bison has nothing to do with my memory.

Thanks for the quick and efficient help!

-- 
Jean Delvare