[ragel] Ragel sanitise output - memory leaks

[Samuel Williams]

I'm not really sure how to answer your questions succinctly.

> Why so strict on building?

Using sanitisers is a great way to find issues in code. Enabling them
across the entire build provides useful feedback and identifies potential
issues. As an example, I also found potential memory alignment issues in
libpng, and zlib-ng.

Turning sanitisers on or off is a matter of choice, so one may choose not
to use them. However, in my case, when enabling them, they apply to all
aspects of the build including compiling the actual ragel binary, since
teapot builds everything from source including supporting tools.

If a tool exits with a non-zero exit status, it's considered a failure.
AFAIK, without being very explicit, I don't believe there is really any way
to tell if ragel failed because of a sanitizer issue or some other issue
with the exit status alone, so it's really just a matter of "the tool
failed, so the build failed". I think that's the right behaviour.

> Does it really matter if a tool used in the build doesn't free everything
before exiting?

If you just consider the nature of the tool and assuming the bug is simply
calling malloc without calling free, sure, I think we can be reasonable and
assume that it doesn't matter if it's a one shot process.

However, as I suggested, these problems might be covering up larger issues.
You won't know until you investigate them.

Additionally, if one chooses to ignore these issues, fair enough, but it's
possible that in the future a more serious issue would be lost in the
noise. I believe that's why things like "-Werror" exist, so that you can't
ignore warnings that might indicate potential problems. The code should
compile and run cleanly, and if not it warrants investigation IMHO.

Kind regards,
Samuel

On 28 January 2018 at 05:24, Adrian Thurston <thurston at colm.net> wrote:

> Why so strict on building? Does it really matter if a tool used in the a
> build doesn't free everything before exiting?
>
> On 2018-01-26 03:59, Samuel Williams wrote:
>
> When sanitisers are on, the exit status is non-zero because of the memory
> leaks, so it's not just clean build reports, but actually failed builds.
>
> Thanks
> Samuel
>
> On 14 December 2017 at 05:22, Adrian Thurston <thurston at colm.net> wrote:
>
>> Sorry, no change. The problems are in the form of memory leaks in ragel
>> mucking up your clean build reports? Maybe you could turn them off for
>> ragel? Honestly it's never really been a strong concern for me since ragel
>> is a one-shot kind of program. Some improvements were made when I added
>> libfsm, but that was mostly in the core FSM code.
>>
>> My current concerns with ragel are to get out-of-tree support for
>> alternate host languages. Will have some time for that in December.
>> Removing leaks is something I would work on when 7.0 gets to stable status.
>>
>> Adrian
>>
>> On 2017-11-08 20:08, Samuel Williams wrote:
>>
>> Any update to this? Still causing problems for me.
>>
>> On 9 October 2017 at 10:34, Samuel Williams <space.ship.traveller at gmail.
>> com> wrote:
>>
>>> Here is some log output from a build which invokes ragel to generate
>>> several parsers. I've cut out (most) unimportant output.
>>>
>>> The source code for the parsers: https://github.com/
>>> kurocha/async-http/tree/master/source/Async/HTTP/V1
>>>
>>> The results from running Ragel several times with LLVM sanitisers:
>>> https://gist.github.com/ioquatix/2e50ffb09697107338f8f75083400143
>>>
>>> The main issue I can see are memory leaks, but there could be other
>>> issues.
>>>
>>> Since Ragel is a one-shot "compiler", perhaps it's not important to
>>> address these, except as a matter of correctness.
>>>
>>> I think there are potential problem with memory leaks and they might be
>>> covering up bigger issues - there might be cases where memory is being
>>> accessed incorrectly but it's not causing a crash because it's not freed at
>>> the right point etc.
>>>
>>> I'd suggest that if there is a test suite for Ragel, it's updated to run
>>> with the undefined behaviour sanitiser and address sanitiser - both provide
>>> useful output IMHO.
>>>
>>> Happy to provide more feedback.
>>>
>>> Kind regards,
>>> Samuel
>>>
>>>
>> _______________________________________________
>> ragel mailing listragel at colm.nethttp://www.colm.net/cgi-bin/mailman/listinfo/ragel
>>
>>
>> _______________________________________________
>> ragel mailing list
>> ragel at colm.net
>> http://www.colm.net/cgi-bin/mailman/listinfo/ragel
>>
>
> _______________________________________________
> ragel mailing listragel at colm.nethttp://www.colm.net/cgi-bin/mailman/listinfo/ragel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.colm.net/pipermail/ragel-users/attachments/20180128/796007fc/attachment-0002.html>