Memory leaks after a compiler error

[ProkopRandacek]

Example input:

import (
	"th.um"
ect.Rect(

The second lexer that is created for the file th.um is not freed when the compiler exits later because of the invalid syntax.

Leak sanitizer backtrace:

==148095==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 256 byte(s) in 1 object(s) allocated from:
    #0 0x563d4f5f7d39 in malloc (/home/prokop/source/umka-lang/build/umka+0x1c7d39)
    #1 0x563d4f678790 in parseImportItem /home/prokop/source/umka-lang/build/../src/umka_decl.c:744:25
    #2 0x563d4f677510 in parseImport /home/prokop/source/umka-lang/build/../src/umka_decl.c:790:13
    #3 0x563d4f66f230 in parseModule /home/prokop/source/umka-lang/build/../src/umka_decl.c:807:9
    #4 0x563d4f66ea5f in parseProgram /home/prokop/source/umka-lang/build/../src/umka_decl.c:824:22
    #5 0x563d4f656c54 in compilerCompile /home/prokop/source/umka-lang/build/../src/umka_compiler.c:206:5
    #6 0x563d4f63e531 in umkaCompile /home/prokop/source/umka-lang/build/../src/umka_api.c:107:9
    #7 0x563d4f993bf4 in main /home/prokop/source/umka-lang/build/../src/umka.c:169:14
    #8 0x7ff7d391d2cf  (/usr/lib/libc.so.6+0x232cf) (BuildId: 9c28cfc869012ebbd43cdb0f1eebcd14e1b8bdd8)

Direct leak of 31 byte(s) in 1 object(s) allocated from:
    #0 0x563d4f5f7d39 in malloc (/home/prokop/source/umka-lang/build/umka+0x1c7d39)
    #1 0x563d4f6d377a in lexInit /home/prokop/source/umka-lang/build/../src/umka_lexer.c:143:20
    #2 0x563d4f64cfe7 in compilerInit /home/prokop/source/umka-lang/build/../src/umka_compiler.c:157:5
    #3 0x563d4f63c2ce in umkaInit /home/prokop/source/umka-lang/build/../src/umka_api.c:94:9
    #4 0x563d4f993baa in main /home/prokop/source/umka-lang/build/../src/umka.c:166:15
    #5 0x7ff7d391d2cf  (/usr/lib/libc.so.6+0x232cf) (BuildId: 9c28cfc869012ebbd43cdb0f1eebcd14e1b8bdd8)

SUMMARY: AddressSanitizer: 287 byte(s) leaked in 2 allocation(s).

the first leak in parseImportItem is already reported in #211

[vtereshkov]

@ProkopRandacek I suppose #211 and #212 are in fact the same issue. Error handling in Umka is based on longjmp(). Unlike C++ exceptions, it does not unwind the stack, nor it calls any destructors. Therefore, memory leaks are always possible after a compiler error. I assume that, after a compiler error, the application immediately terminates, so that the operating system can reclaim all the memory allocated by the application. Of course, if you try to reuse the Umka instance after an error, the leak will still be there.

[skejeton]

@ProkopRandacek I suppose #211 and #212 are in fact the same issue. Error handling in Umka is based on longjmp(). Unlike C++ exceptions, it does not unwind the stack, nor it calls any destructors. Therefore, memory leaks are always possible after a compiler error. I assume that, after a compiler error, the application immediately terminates, so that the operating system can reclaim all the memory allocated by the application. Of course, if you try to reuse the Umka instance after an error, the leak will still be there.

To battle that problem, somewhere in compiler you can store a list of pointers you malloc'd, then just free them all upon an error