<div dir="ltr">Thank you for your reply.<div>A member in my team also suggests so, I think I can have a try on the forking solution. At least, it will make the program "works well" in the production version on the server. If any other related problems occur, I will reply here and hope to discuss about these if you want.</div><div>Thanks again.</div><div><br></div><div>Ella</div></div><br><div class="gmail_quote"><div dir="ltr">Gábor Márton <<a href="mailto:martongabesz@gmail.com">martongabesz@gmail.com</a>> 于2018年6月24日周日 下午5:25写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>We are struggling with the same problem with my team. We work on cross translation unit (CTU) static analysis. Sometimes the AST node of a function imported by the ASTImporter is not complete or wrong which causes assertion failures in the analysis engine or in the checkers. However if we had known that the function could not be imported then we wouldn't have started to import that, this way preventing the assert to fire and the crash of the process. Note, when the assertions are disabled, usually a segmentation fault happens.</div><div><br></div><div>The original intention of the assertions in the LLVM infrastructure is to signal programming errors. They are really useful to catch errors - made by the LLVM/Clang programmer - as early as possible.<br></div><div>See <a href="https://llvm.org/docs/CodingStandards.html#assert-liberally" target="_blank">https://llvm.org/docs/CodingStandards.html#assert-liberally</a> .</div><div><div style="text-decoration-style:initial;text-decoration-color:initial"><span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Generally, we say that we should distinguish between programming errors and errors in the input. Programming errors should be handled with asserts, errors in the input should be handled with other means (some projects use exceptions).</span></div></div><div><div style="text-decoration-style:initial;text-decoration-color:initial">However, in our special case of the CTU, the AST is an input. Which can be wrongly assembled by the ASTImporter. Unfortunately the checkers cannot distinguish whether the error is because of a programming error in the checker itself or whether the AST as an input is wrong.<br></div></div><div style="text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="text-decoration-style:initial;text-decoration-color:initial">Here is what we thought so far: Do a fork before the actual import and if the child died then don't start the import at all. This seems quite complicated and performance issues may arise. Also this may just hide some real errors, so we did not start to implement it. Rather we have the strategy now to gradually fix all the assertions. Sooner or later the ASTImporter will provide a complete and correct AST and the checkers are also changed to be able to handle a crippled AST. Until then we have crashes but every week we have fewer. And very importantly, we plan to hide the crash report from our users since it is useful only to the developers.</div><div style="text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="text-decoration-style:initial;text-decoration-color:initial">Hope this helps,</div><div style="text-decoration-style:initial;text-decoration-color:initial">Gabor</div><div><br></div><div>   <br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jun 24, 2018 at 10:24 AM alan snape via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My team is developing a static analysis tool based on clang and llvm, but the assertion failures in the source code of llvm and clang will always crash the program execution, which is not acceptable in a **stable product**. The tool analyzes the functions one by one in the Call Graph SCC order, so is there any way to tolerate the assertion failures and continue the analysis on the next function when assertion failures occur on calling some APIs of clang and llvm? (crashes only the analysis of the function<span style="text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>(the analysis methods of the FunctionDecl)</span> being analyzed, not the entire program)<div><br></div><div>Thanks,</div><div>Ella</div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
</blockquote></div>