<div dir="ltr">On 25 March 2013 17:52, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">30 seconds seems like rather ta long time to wait. Something in the 1-5s range would be fine, I would think.</blockquote>
<div><br></div><div>Okay, I'll move it to 5s. I prefer to err on the side of waiting longer for the benefit of slower computers. An alternative is to wrap all the records with a timer instead of each entry individually.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Does Clang's unused-private-member warning not complain about Watchdog::Data?</blockquote>
<div><br></div>It does not because the record does not have a trivial constructor and destructor. See InitializationHasSideEffects in SemaDeclCXX.cpp.</div><div class="gmail_quote"><br><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
<div><div><div>On Mon, Mar 25, 2013 at 4:56 PM, Nick Lewycky <span dir="ltr"><<a href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">This patch adds a call to alarm(30) around each call to PrettyStackTraceEntry::print(). I add a new llvm::sys::Watchdog class which takes a number of seconds after which to time out. The implementation is best-effort (the watchdog falls back to doing nothing if we lack an implementation), and is only implemented on Unix with unistd.h. Please review!<div>
<br></div><div>The motivation is a hang-on-crash in clang because clang called into malloc in its pretty stack printer after a crash that occurred inside free. With crashes that time out, the output looks like this:<div>
<br>
</div><div><div>0 clang 0x0000000002fa513e llvm::sys::PrintStackTrace(_IO_FILE*) + 38<br></div><div>1 clang 0x0000000002fa53c5</div><div>2 clang 0x0000000002fa4e14</div><div>3 libpthread.so.0 0x00007f949a699cb0</div>
<div>4 clang 0x0000000001fff407</div><div>5 clang 0x0000000001ffc1f7 clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducerKind, clang::Token&) + 233</div><div>6 clang 0x0000000001ffc1f7 clang::PragmaNamespace::HandlePragma(clang::Preprocessor&, clang::PragmaIntroducerKind, clang::Token&) + 233</div>
<div>7 clang 0x0000000001ffc276 clang::Preprocessor::HandlePragmaDirective(unsigned int) + 124</div><div>8 clang 0x0000000001fe3105 clang::Preprocessor::HandleDirective(clang::Token&) + 1315</div>
<div>9 clang 0x0000000001fc531c clang::Lexer::LexTokenInternal(clang::Token&) + 8850</div><div>10 clang 0x0000000000d6a376</div></div><div><div>11 clang 0x0000000000d6a4f5</div><div>12 clang 0x0000000001fc3294 clang::Lexer::LexTokenInternal(clang::Token&) + 522</div>
<div>13 clang 0x0000000000d6a376</div><div>14 clang 0x0000000000d6a4f5</div><div>15 clang 0x000000000117adb1</div><div>16 clang 0x0000000001173c89 clang::Parser::Initialize() + 2299</div>
<div>17 clang 0x00000000011707be clang::ParseAST(clang::Sema&, bool, bool) + 290</div><div>18 clang 0x0000000000d66da8 clang::ASTFrontendAction::ExecuteAction() + 298</div><div>19 clang 0x0000000000f95694 clang::CodeGenAction::ExecuteAction() + 1414</div>
<div>20 clang 0x0000000000d6692a clang::FrontendAction::Execute() + 200</div><div>21 clang 0x0000000000d3b6dc clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 722</div><div>22 clang 0x0000000000d0b610 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1018</div>
<div>23 clang 0x0000000000cfb487 cc1_main(char const**, char const**, char const*, void*) + 722</div></div><div><div>24 clang 0x0000000000d05beb main + 496</div><div>25 libc.so.6 0x00007f94998d676d __libc_start_main + 237</div>
<div>26 clang 0x0000000000cfab79</div><div>Stack dump:</div><div>0. Program arguments: /usr/local/google/home/nlewycky/llvm/Debug+Asserts/bin/clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj [... lots more ...] -o /tmp/--9Lb3sl.o -x c++ - </div>
</div><div><div>1. clang: error: unable to execute command: Alarm clock</div><div>clang: error: clang frontend command failed due to signal (use -v to see invocation)</div><div>clang version 3.3 (trunk 177917) (llvm/trunk 177901)</div>
<div>Target: x86_64-unknown-linux-gnu</div><div>Thread model: posix</div><div>clang: note: diagnostic msg: PLEASE submit a bug report to <a href="http://llvm.org/bugs/" target="_blank">http://llvm.org/bugs/</a> and include the crash backtrace, preprocessed source, and associated run script.</div>
<span><font color="#888888">
</font></span></div><span><font color="#888888"><div><br></div><div>Nick</div><div><br></div></font></span></div></div>
</blockquote></div><br></div></div>
</div></div></blockquote></div><br></div></div>