search

fbb-git / flexcpp

Flexc++ is a scanner generator like flex, but it generates C++ code
31 stars 11 forks source link

Generated code should be sanitized #1

Closed gendx closed 9 years ago

gendx commented 9 years ago

Hi, I created a simple program that uses flexc++ to generate a lexer (along with bisonc++ for a parser), and compiled it with -fsanitize=leak. I got a memory leak from the lexer code generated by flexc++ :

Direct leak of 280 byte(s) in 1 object(s) allocated from:
    #0 0x7f399f313be8 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xbbe8)
    #1 0x4055b1 in ScannerBase::ScannerBase(std::istream&, std::ostream&) ../src/parse/lex.cc:797

It seems that the skeleton file https://github.com/fbb-git/flexcpp/blob/master/flexc%2B%2B/skeletons/flexc%2B%2B.cc does not properly manage the memory for the input/output streams.

fbb-git commented 9 years ago

Dear gendx, you wrote:

Hi, I created a simple program that uses flexc++ to generate a lexer (along with bisonc++ for a parser), and compiled it with -fsanitize=leak. I got a memory leak from the lexer code generated by flexc++ :

Direct leak of 280 byte(s) in 1 object(s) allocated from:
    #0 0x7f399f313be8 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xbbe8)
    #1 0x4055b1 in ScannerBase::ScannerBase(std::istream&, std::ostream&) ../src/parse/lex.cc:797

It seems that the skeleton file https://github.com/fbb-git/flexcpp/blob/master/flexc%2B%2B/skeletons/flexc%2B%2B.cc does not properly manage the memory for the input/output streams.

Thanks for the `heads up'. It's probably caused by the ScannerBase::Input class: ScannerBase's d_input data member is initialized by ScannerBase's constructor, but Input's destructor does not return the memory allocated by ScannerBase's constructor. If that's causing the leak then it's just a one-time event, and not a dynamically growing leak. I'll try to fix this flaw at the next release.

Thanks again!

Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA
gendx commented 9 years ago

If that's causing the leak then it's just a one-time event, and not a dynamically growing leak.

Well it's true when there is only one instance of the class, which might not be the case in complex programs. A memory leak is seldom a good idea.

fbb-git commented 9 years ago

Dear gendx, you wrote:

If that's causing the leak then it's just a one-time event, and not a dynamically growing leak.

Well it's true when there is only one instance of the class, which might not be the case in complex programs. A memory leak is seldom a good idea.

I couldn't agree more. But the new release is already available at my computer. I'll probably push it to github later today or early tomorrow (UTC). Valgrind no longer reports a leak after calling d_input.close() in ScannerBase's destructor (see also section 18 in the flexc++api(3) man-page).

Frank B. Brokken
Center for Information Technology, University of Groningen
(+31) 50 363 9281 
Public PGP key: http://pgp.surfnet.nl
Key Fingerprint: DF32 13DE B156 7732 E65E  3B4D 7DB2 A8BE EAE4 D8AA
fbb-git commented 9 years ago

According to valgrind commit 80aa7b10bc9b738396289c40ef12dd505f9a7bd6 fixes the memory leak. This commit also uses readlink -f' rather thanrealpath', and fixes a potential problem when using tar for installing files at their final destinations.