#6 Flex c++ scanner still leaks memory

2.5.33
closed-fixed
Will Estes
C++ (13)
5
2006-10-20
2006-02-23
Erik Johansson
No

This bug
http://sourceforge.net/tracker/?group_id=72099&atid=533377&func=detail&aid=928352
and this
http://sourceforge.net/tracker/?group_id=72099&atid=533377&func=detail&aid=1292395
is still valid (cvs 2006-02-23). They've been closed
as duplicates, but there is no reference to the bug
they are duplicate of, so I can only guess that it's
this bug
http://sourceforge.net/tracker/?group_id=72099&atid=533377&func=detail&aid=1269157.
But the solution to that bug is not enough, the
scanner still leaks memory.

The problem is that the stack is not freed. The
attached patch fixes this by making the yyFlexLexer
destructor use the same code as yylex_destroy.

I have confirmed that the patch fixes a memory leak I
was having in my c++ scanner. I've also been running
valgrind on some of the tests and can confirm that
the patch (together with small fixes of the tests
themself) fixes memory leaks in those as well.

Discussion

  • Erik Johansson
    Erik Johansson
    2006-02-23

    Makes yyFlexLexer::~yyFlexLexer use the same code as yylex_destroy

     
    Attachments
  • Erik Johansson
    Erik Johansson
    2006-02-23

    Removes memory leak from the test test-c-cpp-nr

     
  • Erik Johansson
    Erik Johansson
    2006-02-23

    Removes memory leak from the test test-c++-multiple-scanners

     
  • Logged In: NO

    I should start off every C++ bug comment with the README
    below, so that we're all on the same page.

    ---- "C++ Scanner README" ----
    This is by no means aimed at the current bug or its author -
    - I'm just trying to head off the C++ bug reports since most
    of them will be stuff already fixed in the C scanner.

    The C++ scanner was, and is experimental. It is also dead
    weight in the sense that there is no task for the C++
    scanner that you can't trivially accomplish with the C
    scanner. Worse, the C++ scanner is broken in places that
    have long since been fixed in the C scanner. We plan to
    refactor the C++ scanner, or even scrap it, possibly
    breaking the API. (But we'll avoid breaking the API as best
    we can.)

    Here's what we DON'T want: To maintain two separate
    scanners. My advice is to not use the C++ scanner moving
    forward. To those of you currently using the C++ scanner,
    please be patient. Realize that you are using experimental
    code and should not expect stability or longevity. To
    refactor your code to use C scanner would probably take an
    hour, and is probably the best course of action for you.
    Thank you for reading.
    ----

    Ok, On the subject of the current bug. The stack leak has
    long since been fixed in the C scanner. The real solution to
    this is to refactor the C++ scanner to use the C scanner
    "under the hood". I think this patch does just that. Let's
    see! -John

     
  • Logged In: YES
    user_id=593185

    >>Ok, On the subject of the current bug. The stack leak
    has long since been fixed in the C scanner. The real
    solution to this is to refactor the C++ scanner to use the
    C scanner "under the hood". I think this patch does just
    that. Let's see! -John<<

    But what about reentrant scanners? This whole thing that
    the C++ scanner is 'broken' is not covered in the docs,
    that recommend using it for reentrant scanners.

    I'll join the mailling list and continue this discussion
    there ...

     
  • Will Estes
    Will Estes
    2006-10-19

    • assigned_to: nobody --> wlestes
     
  • Will Estes
    Will Estes
    2006-10-20

    • status: open --> closed-fixed
     
  • Will Estes
    Will Estes
    2006-10-20

    Logged In: YES
    user_id=595627

    patches applied; but John's notes are definitely correct.
    We may alter the C++ scanner in deep ways without notice.
    C++ scanners in flex are experimental.