fix a memleak in snowball compiler #166
Conversation
When an output file is used and the name option is not, then the compiler will dynamically allocate value for the `name` option and never free it. This is not a large problem, because at the end of the compile process the OS will free all allocated memory anyway. However, when using snowball as part of a larger toolchain and then using compile options such as `-fsanitize=leak`, a memleak in snowball can break the entire build. This exactly what happened to us. We could work around this somehow, but it seems better to fix the leak in the compiler properly. The same issue was already reported previously by a former colleague of mine in snowballstem#136, but that PR seemingly was disliked by the snowball maintainers. Trying it again with this PR with a slightly modified solution and hope it can be merged now.
|
2 out of 18 Travis CI sub-jobs failed during |
This fixes a memleak in the snowball compiler during generation of the language-specific C files. The memleak currently makes our ASan-/LSan-instrumented builds fail. The same fix was suggested to upstream snowball via snowballstem/snowball#166 but is still waiting on feedback there.
|
Is there a chance this PR can make it into a future version of snowball? |
|
Any chance this PR can make it into a future version of snowball? |
|
I'll merge the patch, but I'd really strongly recommend using Doing that would address the issue for you once and for all; otherwise next time the code changes such that something is allocated and not released on exit you'll have to spend time submitting another patch and I'll have to spend time reviewing and applying it. |
|
This patch introduce a bogus |
When an output file is used and the name option is not, then the
compiler will dynamically allocate value for the
nameoption and neverfree it.
This is not a large problem, because at the end of the compile process
the OS will free all allocated memory anyway.
However, when using snowball as part of a larger toolchain and then
using compile options such as
-fsanitize=leak, a memleak in snowballcan break the entire build.
This exactly what happened to us. We could work around this somehow, but
it seems better to fix the leak in the compiler properly.
The same issue was already reported previously by a former colleague of
mine in #136, but that PR
seemingly was disliked by the snowball maintainers. Trying it again with
this PR with a slightly modified solution and hope it can be merged now.