Re: [Flex-help] memory leaks even after yy_delete_buffer(YY_CURRENT_BUFFER)
flex is a tool for generating scanners
Brought to you by:
wlestes
From: Aaron S. <aa...@se...> - 2007-03-31 11:41:13
|
Either from an EOF rule in the parser, because as that point it won't call the lexer anymore, or from outside the parser, after it is done. That should resolve the 4 byte leak, and if it doesn't then there might really be a bug! On Sat, 2007-03-31 at 10:09 +0200, Lorenzo Bettini wrote: > OK, I see... so I should call that from within the parser? > > but would that solve the 4 bytes leak? > > Aaron Stone wrote: > > It's a bad idea to burn down the house when you are inside... > > > > The EOF rule is a good place to clean up memory that you have allocated, > > but a very bad place to clean up the lexer; you are still inside the lexer > > during the EOF rule! > > > > Aaron > > > > On Fri, Mar 30, 2007, Lorenzo Bettini <be...@ds...> said: > > > > > >>I tried to use yylex_destroy() instead of > >>yy_delete_buffer(YY_CURRENT_BUFFER) but I get the same leak anyway: > >> > >>==7612== 4 bytes in 1 blocks are still reachable in loss record 1 of 3 > >>==7612== at 0x40215CD: malloc (in > >>/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > >>==7612== by 0x8070F98: stylecsssc_alloc(unsigned) > >>(stylecssscanner.cc:2172) > >>==7612== by 0x8071013: stylecsssc_ensure_buffer_stack() > >>(stylecssscanner.cc:1909) > >>==7612== by 0x8071C89: stylecsssc_lex() (stylecssscanner.cc:893) > >>==7612== by 0x806F4DB: stylecsssc_parse() (stylecssparser.cc:1341) > >>==7612== by 0x80705E6: parseCssStyles(std::string const&, std::string > >>const&, GeneratorFactory*, std::string&) (stylecssparser.yy:211) > >>==7612== by 0x8051189: StartApp::start(int, char**) (startapp.cc:404) > >>==7612== by 0x8055782: main (source-highlight.cc:26) > >> > >>so the problem still remains... > >> > >>by the way, I tried to call yylex_destroy directly from the <<EOF>> rule > >>but I get an error by the compiler saying that that function is not > >>defined in that scope... > >> > >>I had to define a function at the end of the .ll file where I call > >>yylex_destroy and call this function from the <<EOF>> rule... > >> > >>Aaron Stone wrote: > >> > >>>The post referenced in Paul's email is not coming up this morning, but I > >>>think you're just missing a call to yylex_destroy(). > >>> > >>>Aaron > >>> > >>>On Fri, 2007-03-23 at 11:00 +0100, Lorenzo Bettini wrote: > >>> > >>>>Hi Paul > >>>> > >>>>as far as I understand this patch is for C++ scanner, while in my case > >>>>it's a C scanner, or am I missing something? > >>>> > >>>>thanks > >>>> Lore > >>>> > >>>>Paul Swoboda wrote: > >>>> > >>>>>Hey Lorenzo, > >>>>> > >>>>>"Yuri" sent me this, and it cured that exact leak nicely: > >>>>> > >>>>>----------------------------- > >>>>> > >>>>>That is true! I've submited that in > >>>>>http://sourceforge.net/mailarchive/forum.php?thread_id=31561058&forum_id=39108 > >>>>><http://sourceforge.net/mailarchive/forum.php?thread_id=31561058&forum_id=39108>. > >>>>>You should edit the file flex.skl to add missing string and recompile > >>>>>your copy of flex. > >>>>> > >>>>>----------------------------- > >>>>> > >>>>>Regards, > >>>>> > >>>>>Paul > >>>>> > >>>>> > >>>>>On 3/23/07, *Lorenzo Bettini* <be...@ds... > >>>>><mailto:be...@ds...>> wrote: > >>>>> > >>>>> Hi > >>>>> > >>>>> I'm using flex version 2.5.31 and I was experiencing some memory leaks > >>>>> (using valgrind); actually they were still reachable bytes (16438 > >>>>> bytes). > >>>>> > >>>>> After checking the manual, > >>>>> http://flex.sourceforge.net/manual/Memory-leak-_002d-16386-bytes-allocated-by-malloc_002e.html#Memory-leak-_002d-16386-bytes-allocated-by-malloc_002e > >>>>> <http://flex.sourceforge.net/manual/Memory-leak-_002d-16386-bytes-allocated-by-malloc_002e.html#Memory-leak-_002d-16386-bytes-allocated-by-malloc_002e> > >>>>> > >>>>> I added this rule in the scanner > >>>>> > >>>>> <<EOF>> { > >>>>> /* For non-reentrant C scanner only. */ > >>>>> yy_delete_buffer(YY_CURRENT_BUFFER); > >>>>> > >>>>> yyterminate(); > >>>>> } > >>>>> > >>>>> however, there are still 4 bytes still reachable: > >>>>> > >>>>> ==31245== 4 bytes in 1 blocks are still reachable in loss record 1 of 3 > >>>>> ==31245== at 0x4021618: malloc (in > >>>>> /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) > >>>>> ==31245== by 0x8069B72: stylesc_alloc(unsigned) ( > >>>>> stylescanner.cc:1909) > >>>>> ==31245== by 0x8069BED: stylesc_ensure_buffer_stack() > >>>>> (stylescanner.cc:1646) > >>>>> ==31245== by 0x806A98B: stylesc_lex() (stylescanner.cc:753) > >>>>> ==31245== by 0x8066F67: stylesc_parse() ( styleparser.cc:1344) > >>>>> ==31245== by 0x8067F60: parseStyles(std::string const&, std::string > >>>>> const&) (styleparser.yy:177) > >>>>> ==31245== by 0x80505FB: StartApp::start(int, char**) > >>>>> (startapp.cc:300) > >>>>> ==31245== by 0x8055892: main ( source-highlight.cc:26) > >>>>> > >>>>> am I still missing something? > >>>>> > >>>> > >>> > >> > >>-- > >>Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze > >>ICQ# lbetto, 16080134 (GNU/Linux User # 158233) > >>HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com > >>BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com > >>http://www.gnu.org/software/src-highlite > >>http://www.gnu.org/software/gengetopt > >>http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net > >> > >>------------------------------------------------------------------------- > >>Take Surveys. Earn Cash. Influence the Future of IT > >>Join SourceForge.net's Techsay panel and you'll get the chance to share your > >>opinions on IT & business topics through brief surveys-and earn cash > >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > >>_______________________________________________ > >>Flex-help mailing list > >>Fle...@li... > >>https://lists.sourceforge.net/lists/listinfo/flex-help > >> > > > > > > |