<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.E-MailFormatvorlage18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=DE link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>please have a look at <a href="https://reviews.llvm.org/D34876">https://reviews.llvm.org/D34876</a> where I reverted this assertion. I’m having ulimit –s unlimited. Can you please explain why having such a large stack is actually a bad thing?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Jonas<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Kostya Serebryany [mailto:kcc@google.com] <br><b>Sent:</b> Wednesday, July 12, 2017 12:20 AM<br><b>To:</b> Hahnfeld, Jonas <Hahnfeld@itc.rwth-aachen.de><br><b>Cc:</b> llvm-commits@lists.llvm.org<br><b>Subject:</b> Re: [compiler-rt] r304598 - [asan] fix one more case where stack-use-after-return is not async-signal-safe (during thread startup). beef-up the test to give it a chance to catch regressions. Also relax the lint to make C++11 more usable.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>sorry for delay... <o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Yes, CHECK_LE(stack_size, 0x10000000); is intentional. <o:p></o:p></p><div><p class=MsoNormal>Do you really have 1Gb stacks? <o:p></o:p></p></div></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Jun 26, 2017 at 2:04 AM, Hahnfeld, Jonas <<a href="mailto:Hahnfeld@itc.rwth-aachen.de" target="_blank">Hahnfeld@itc.rwth-aachen.de</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>Hi,<o:p></o:p></p><div><div><p class=MsoNormal><br>-----Original Message-----<br>From: llvm-commits [mailto:<a href="mailto:llvm-commits-bounces@lists.llvm.org">llvm-commits-bounces@lists.llvm.org</a>] On Behalf Of<br>Kostya Serebryany via llvm-commits<br>Sent: Friday, June 2, 2017 11:32 PM<br>To: <a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>Subject: [compiler-rt] r304598 - [asan] fix one more case where<br>stack-use-after-return is not async-signal-safe (during thread startup).<br>beef-up the test to give it a chance to catch regressions. Also relax the lint<br>to make C++11 more usable.<br><br>Author: kcc<br>Date: Fri Jun 2 16:32:04 2017<br>New Revision: 304598<br><br>URL: <a href="http://llvm.org/viewvc/llvm-project?rev=304598&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=304598&view=rev</a><br>Log:<br>[asan] fix one more case where stack-use-after-return is not async-signal-safe<br>(during thread startup). beef-up the test to give it a chance to catch<br>regressions. Also relax the lint to make C++11 more usable.<br><br>Modified:<br> compiler-rt/trunk/lib/asan/asan_thread.cc<br> compiler-rt/trunk/lib/sanitizer_common/scripts/check_lint.sh<br> compiler-rt/trunk/test/asan/TestCases/Linux/uar_signals.cc<br><br>Modified: compiler-rt/trunk/lib/asan/asan_thread.cc<br>URL:<br><a href="http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_thread.cc?rev=304598&r1=304597&r2=304598&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/asan_thread.cc?rev=304598&r1=304597&r2=304598&view=diff</a><br>==============================================================================<br>--- compiler-rt/trunk/lib/asan/asan_thread.cc (original)<br>+++ compiler-rt/trunk/lib/asan/asan_thread.cc Fri Jun 2 16:32:04 2017<br>@@ -166,16 +166,19 @@ void AsanThread::FinishSwitchFiber(FakeS<br> }<br><br> inline AsanThread::StackBounds AsanThread::GetStackBounds() const {<br>- if (!atomic_load(&stack_switching_, memory_order_acquire))<br>- return StackBounds{stack_bottom_, stack_top_}; // NOLINT<br>+ if (!atomic_load(&stack_switching_, memory_order_acquire)) {<br>+ // Make sure the stack bounds are fully initialized.<br>+ if (stack_bottom_ >= stack_top_) return {0, 0};<br>+ return {stack_bottom_, stack_top_}; }<o:p></o:p></p></div></div><p class=MsoNormal> char local;<br> const uptr cur_stack = (uptr)&local;<br> // Note: need to check next stack first, because FinishSwitchFiber<br> // may be in process of overwriting stack_top_/bottom_. But in such case<br> // we are already on the next stack.<br> if (cur_stack >= next_stack_bottom_ && cur_stack < next_stack_top_)<br>- return StackBounds{next_stack_bottom_, next_stack_top_}; // NOLINT<br>- return StackBounds{stack_bottom_, stack_top_}; // NOLINT<br>+ return {next_stack_bottom_, next_stack_top_}; return<br>+ {stack_bottom_, stack_top_};<br> }<br><br> uptr AsanThread::stack_top() {<br>@@ -197,6 +200,7 @@ FakeStack *AsanThread::AsyncSignalSafeLa<br> uptr stack_size = this->stack_size();<br> if (stack_size == 0) // stack_size is not yet available, don't use<br>FakeStack.<br> return nullptr;<br>+ CHECK_LE(stack_size, 0x10000000);<br><br>Was this change intended to be committed? I get quite some failures on my<br>CentOS 7 with this:<br>==31552==AddressSanitizer CHECK failed:<br>[...]/projects/compiler-rt/lib/asan/asan_thread.cc:203 "((stack_size)) <=<br>((0x10000000))" (0x40000000, 0x10000000)<br><br>Removing this check "fixes" the failures.<br><br>Cheers,<br>Jonas<o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>