[ragel] Ragel sanitise output - memory leaks

[Adrian Thurston]

Yeah it's definitely valuable, I periodically do a run of development
centered around cleaning up leaks that impeded ongoing memory usage, but
if the free() is the last thing you're about to do before calling
exit(), I'd just rather call exit(). 

Adrian 

On 2018-01-27 17:53, Samuel Williams wrote: 

> 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 [2] 
> The results from running Ragel several times with LLVM sanitisers: https://gist.github.com/ioquatix/2e50ffb09697107338f8f75083400143 [3]
> 
> 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 list
> ragel at colm.net
> http://www.colm.net/cgi-bin/mailman/listinfo/ragel [1]

_______________________________________________
 ragel mailing list
 ragel at colm.net
 http://www.colm.net/cgi-bin/mailman/listinfo/ragel [1] 

_______________________________________________
ragel mailing list
ragel at colm.net
http://www.colm.net/cgi-bin/mailman/listinfo/ragel [1]

 

Links:
------
[1] http://www.colm.net/cgi-bin/mailman/listinfo/ragel
[2]
https://github.com/kurocha/async-http/tree/master/source/Async/HTTP/V1
[3] https://gist.github.com/ioquatix/2e50ffb09697107338f8f75083400143
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.colm.net/pipermail/ragel-users/attachments/20180128/b051164c/attachment-0002.html>