[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Memory leak in bison-generated code

From: Jean Delvare
Subject: Memory leak in bison-generated code
Date: Fri, 6 Feb 2009 17:54:48 +0100

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 
==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

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
        * 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?


Jean Delvare

reply via email to

[Prev in Thread] Current Thread [Next in Thread]