Memory leak in bison-generated code

[Jean Delvare]

Hi all,

Valgrind tells me that there's a memory leak in libsensors [1], in code
which is generated by flex/bison:

==15124== 72 bytes in 1 blocks are still reachable in loss record 1 of 1
==15124==    at 0x4C25741: realloc (in 
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==15124==    by 0x4E316B4: sensors_yyrealloc (<stdout>:2807)
==15124==    by 0x4E3176D: sensors_yyensure_buffer_stack (<stdout>:2513)
==15124==    by 0x4E31834: sensors_yy_switch_to_buffer (<stdout>:2289)
==15124==    by 0x4E31B97: sensors_scanner_init (conf-lex.l:345)
==15124==    by 0x4E2F2A4: sensors_init (init.c:85)
==15124==    by 0x4015B0: main (main.c:108)

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
        <http://lists.gnu.org/archive/html/bison-patches/2006-11/msg00014.html>.
        * src/flex-scanner.h (yylex_destroy): Define for Flex before 2.5.9.
        * src/scan-code.l (translate_action): Don't bother invoking
        yy_delete_buffer (YY_CURRENT_BUFFER) before creating the first buffer.
        (code_scanner_free): Instead of invoking
        yy_delete_buffer (YY_CURRENT_BUFFER) directly, invoke yylex_destroy,
        which frees more.
        * src/scan-gram.l (gram_scanner_free): Likewise.
        * src/scan-skel.l (scan_skel): Likewise.

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?

[1] http://dl.lm-sensors.org/lm-sensors/releases/lm_sensors-3.0.3.tar.bz2

Thanks,
-- 
Jean Delvare