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 <jde...@ces.clemson.edu> 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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison