patch: watchdog timer for pretty stack trace entries

[Nick Lewycky]

On 25 March 2013 17:52, Richard Smith <richard at metafoo.co.uk> wrote:

> 30 seconds seems like rather ta long time to wait. Something in the 1-5s
> range would be fine, I would think.


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.


> Does Clang's unused-private-member warning not complain about
> Watchdog::Data?


It does not because the record does not have a trivial constructor and
destructor. See InitializationHasSideEffects in SemaDeclCXX.cpp.

Nick

 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/07f66e7e/attachment.html>