patch: watchdog timer for pretty stack trace entries

[Richard Smith]

30 seconds seems like rather ta long time to wait. Something in the 1-5s
range would be fine, I would think. Does Clang's unused-private-member
warning not complain about Watchdog::Data?

On Mon, Mar 25, 2013 at 4:56 PM, Nick Lewycky <nlewycky at google.com> wrote:

> 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!
>
> 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:
>
> 0  clang           0x0000000002fa513e
> llvm::sys::PrintStackTrace(_IO_FILE*) + 38
> 1  clang           0x0000000002fa53c5
> 2  clang           0x0000000002fa4e14
> 3  libpthread.so.0 0x00007f949a699cb0
> 4  clang           0x0000000001fff407
> 5  clang           0x0000000001ffc1f7
> clang::PragmaNamespace::HandlePragma(clang::Preprocessor&,
> clang::PragmaIntroducerKind, clang::Token&) + 233
> 6  clang           0x0000000001ffc1f7
> clang::PragmaNamespace::HandlePragma(clang::Preprocessor&,
> clang::PragmaIntroducerKind, clang::Token&) + 233
> 7  clang           0x0000000001ffc276
> clang::Preprocessor::HandlePragmaDirective(unsigned int) + 124
> 8  clang           0x0000000001fe3105
> clang::Preprocessor::HandleDirective(clang::Token&) + 1315
> 9  clang           0x0000000001fc531c
> clang::Lexer::LexTokenInternal(clang::Token&) + 8850
> 10 clang           0x0000000000d6a376
> 11 clang           0x0000000000d6a4f5
> 12 clang           0x0000000001fc3294
> clang::Lexer::LexTokenInternal(clang::Token&) + 522
> 13 clang           0x0000000000d6a376
> 14 clang           0x0000000000d6a4f5
> 15 clang           0x000000000117adb1
> 16 clang           0x0000000001173c89 clang::Parser::Initialize() + 2299
> 17 clang           0x00000000011707be clang::ParseAST(clang::Sema&, bool,
> bool) + 290
> 18 clang           0x0000000000d66da8
> clang::ASTFrontendAction::ExecuteAction() + 298
> 19 clang           0x0000000000f95694
> clang::CodeGenAction::ExecuteAction() + 1414
> 20 clang           0x0000000000d6692a clang::FrontendAction::Execute() +
> 200
> 21 clang           0x0000000000d3b6dc
> clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 722
> 22 clang           0x0000000000d0b610
> clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1018
> 23 clang           0x0000000000cfb487 cc1_main(char const**, char const**,
> char const*, void*) + 722
> 24 clang           0x0000000000d05beb main + 496
> 25 libc.so.6       0x00007f94998d676d __libc_start_main + 237
> 26 clang           0x0000000000cfab79
> Stack dump:
> 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++ -
> 1.      clang: error: unable to execute command: Alarm clock
> clang: error: clang frontend command failed due to signal (use -v to see
> invocation)
> clang version 3.3 (trunk 177917) (llvm/trunk 177901)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
> clang: note: diagnostic msg: PLEASE submit a bug report to
> http://llvm.org/bugs/ and include the crash backtrace, preprocessed
> source, and associated run script.
>
> Nick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130325/118caa62/attachment.html>