<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 21, 2017, at 1:47 PM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Feb 15, 2017 at 11:02 AM Greg Clayton <<a href="mailto:gclayton@apple.com" class="">gclayton@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">The other thing is on Mac we add new flags to mmap that allow us not to crash if the backing store (network mount) goes away. There is also a flag that says "if code signature is borked, please still allow me to read the file without crashing. That functionality will need to be ported into the LLVM code somehow so we don't start crashing again. Previously we would crash if someone would do:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">(lldb) file /tmp/invalid_codesig_app</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">And also if the network mounted share would go away on something that was mmap'ed and someone would touch any byte within it. Our version of mmap works around this and we need that to be in any version we adopt.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Greg</div></div></blockquote><div class=""><br class=""></div><div class="">Hi Greg,</div><div class=""><br class=""></div><div class="">I tried to get a change into LLVM to add these two flags. However, I started getting some buildbot <a href="http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental_check/33988/consoleFull#-14904194218254eaf0-7326-4999-85b0-388101f2d404" class="">failures</a> that only occurred on OSX with the error message "The operation is not permitted". Since it was only on OSX, and since it mentioned permissions, I suspect that MAP_RESILIENT_CODESIGN and MAP_RESILIENT_MEDIA are causing a problem. Do you know what the requirements of using these two flags are? And why they might fail?</div></div></div></div></blockquote><div><br class=""></div>We don't seem to have problems with them in LLDB. Not sure how they are being used in LLVM/Clang and why that would cause any problems. You might check the system console and see if the sandbox is not letting you use those. We haven't had any problems with them in LLDB. Maybe some bots are running an older version of the OS that doesn't support those?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">I'm guessing you can reproduce my issue locally by checking out up to r<span style="color:rgb(51,51,51);font-family:helvetica,arial,sans-serif;font-size:13px" class="">295769 and then running "ninja check-llvm".</span><span style="color:rgb(51,51,51);font-family:helvetica,arial,sans-serif" class=""> How come LLDB doesn't fail but LLVM does when using these flags?</span></div></div></div>
</div></blockquote><br class=""></div><div>No idea. Check the system console.</div><br class=""></body></html>