<div dir="ltr"><div>I'm not really sure how to answer your questions succinctly.</div><div><br></div><div>> Why so strict on building?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>> Does it really matter if a tool used in the build doesn't free everything before exiting?</div><div><div style="font-size:12.800000190734863px"><br></div></div><div>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.</div><div><br></div><div>However, as I suggested, these problems might be covering up larger issues. You won't know until you investigate them.</div><div><br></div><div>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.</div><div><br></div><div>Kind regards,</div><div>Samuel</div><div><div class="gmail_extra"><br><div class="gmail_quote">On 28 January 2018 at 05:24, Adrian Thurston <span dir="ltr"><<a href="mailto:thurston@colm.net" target="_blank">thurston@colm.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><u></u>
<div style="font-size:14pt;font-family:Verdana,Geneva,sans-serif">
<p>Why so strict on building? Does it really matter if a tool used in the a build doesn't free everything before exiting?</p><div><div class="gmail-h5">
<p>On 2018-01-26 03:59, Samuel Williams wrote:</p>
<blockquote type="cite" style="padding-left:5px;border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px">
<div dir="ltr">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.
<div> </div>
<div>Thanks</div>
<div>Samuel<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 14 December 2017 at 05:22, Adrian Thurston <span><<a href="mailto:thurston@colm.net" target="_blank">thurston@colm.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="text-decoration:underline"></span>
<div style="font-size:14pt;font-family:Verdana,Geneva,sans-serif">
<p>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.</p>
<p>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.</p>
<p>Adrian</p>
<div>
<div class="gmail-m_-3837407515989013354h5">
<p>On 2017-11-08 20:08, Samuel Williams wrote:</p>
</div>
</div>
<blockquote style="padding-left:5px;border-left-width:2px;border-left-style:solid;border-left-color:rgb(16,16,255);margin-left:5px">
<div>
<div class="gmail-m_-3837407515989013354h5">
<div dir="ltr">Any update to this? Still causing problems for me.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 9 October 2017 at 10:34, Samuel Williams <span><<a href="mailto:space.ship.traveller@gmail.com" target="_blank">space.ship.traveller@gmail.<wbr>com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Here is some log output from a build which invokes ragel to generate several parsers. I've cut out (most) unimportant output.</div>
<div> </div>
<div>The source code for the parsers: <a href="https://github.com/kurocha/async-http/tree/master/source/Async/HTTP/V1" target="_blank">https://github.com/<wbr>kurocha/async-http/tree/<wbr>master/source/Async/HTTP/V1</a></div>
<div> </div>
The results from running Ragel several times with LLVM sanitisers: <a href="https://gist.github.com/ioquatix/2e50ffb09697107338f8f75083400143" target="_blank">https://gist.github.com/<wbr>ioquatix/<wbr>2e50ffb09697107338f8f750834001<wbr>43</a><br>
<div> </div>
<div>The main issue I can see are memory leaks, but there could be other issues.</div>
<div> </div>
<div>Since Ragel is a one-shot "compiler", perhaps it's not important to address these, except as a matter of correctness.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>Happy to provide more feedback.</div>
<div> </div>
<div>Kind regards,</div>
<div>Samuel</div>
<div> </div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<pre>______________________________<wbr>_________________
ragel mailing list
<a href="mailto:ragel@colm.net" target="_blank">ragel@colm.net</a>
<a href="http://www.colm.net/cgi-bin/mailman/listinfo/ragel" target="_blank">http://www.colm.net/cgi-bin/<wbr>mailman/listinfo/ragel</a>
</pre>
</blockquote>
</div>
<br>______________________________<wbr>_________________<br> ragel mailing list<br> <a href="mailto:ragel@colm.net" target="_blank">ragel@colm.net</a><br> <a href="http://www.colm.net/cgi-bin/mailman/listinfo/ragel" target="_blank">http://www.colm.net/cgi-bin/<wbr>mailman/listinfo/ragel</a><br> </blockquote>
</div>
</div>
</div>
</div>
</div>
<br>
<pre>______________________________<wbr>_________________
ragel mailing list
<a href="mailto:ragel@colm.net" target="_blank">ragel@colm.net</a>
<a href="http://www.colm.net/cgi-bin/mailman/listinfo/ragel" target="_blank">http://www.colm.net/cgi-bin/<wbr>mailman/listinfo/ragel</a>
</pre>
</blockquote>
</div></div></div>
</blockquote></div><br></div></div></div>