This is an archive of the discontinued LLVM Phabricator instance.

[asan] Optionally print reproducer cmdline in ASan reports.
ClosedPublic

Authored by m.ostapenko on Jan 11 2016, 8:49 AM.

Details

Summary

Hi,

for big systems, sometimes it would be nice to extract reproducer cmdline from ASan report to perform further debugging. Actually, sanitizer library already contains necessary functionality and this patch just uses existing GetArgsAndEnv routine to print this information in ASan report destructor.

Diff Detail

Repository
rL LLVM

Event Timeline

m.ostapenko retitled this revision from to [asan] Optionally print reproducer cmdline in ASan reports..
m.ostapenko updated this object.
m.ostapenko added reviewers: kcc, eugenis, samsonov.
m.ostapenko set the repository for this revision to rL LLVM.
m.ostapenko added subscribers: llvm-commits, ygribov.
ygribov added inline comments.Jan 11 2016, 9:13 AM
lib/asan/asan_report.cc
243 ↗(On Diff #44515)

This will leak memory (not sure if it's important).

246 ↗(On Diff #44515)

size_t?

lib/sanitizer_common/sanitizer_common.h
285 ↗(On Diff #44515)

Stars bind to right.

m.ostapenko added inline comments.Jan 11 2016, 9:30 AM
lib/asan/asan_report.cc
246 ↗(On Diff #44515)

size_t is not accessible from ASan code... will use uptr like in many other places.

lib/sanitizer_common/sanitizer_common.h
285 ↗(On Diff #44515)

This was just copied from sanitizer_linux.cc. Perhaps I should fix stars binding there as well.

m.ostapenko removed rL LLVM as the repository for this revision.

Updating according to Yura's nits.

kcc edited edge metadata.Jan 11 2016, 12:52 PM

Will this link on non-linux?
You've inserted a call to GetArgsAndEnv into the main path, while GetArgsAndEnv remains in linux-specific code.

test/asan/TestCases/Posix/print_cmdline.cc
5 ↗(On Diff #44523)

Why not use the same CHECK prefix for the first two lines?

m.ostapenko edited edge metadata.
m.ostapenko set the repository for this revision to rL LLVM.
m.ostapenko added a subscriber: kubamracek.

Updating according to Kostya's nits. Encapsulate target specific code in GetArgv function, implemented for Linux and Mac. Tested on Linux box. For Mac, GetArgv seems to be trivial, but I'd still prefer OS X guys to take a look. For Windows I left it unimplemented, thought we can use something like GetCommandLine API function to extract Argv.

filcab added a subscriber: filcab.Jan 12 2016, 5:36 AM

Why call it a "reproducer", though?
The command line is just one of the various inputs to a program.

Since it isn't guaranteed to "reproduce" the problem, I'd prefer to just remove that word. Something like:

Command line: ...

works perfectly (or even just Command: ...). It also gets rid of the abbreviation in the UI :-)

Thanks!

Why call it a "reproducer", though?
The command line is just one of the various inputs to a program.

Sounds reasonable, thanks. Updating the patch.

kcc added a comment.Jan 13 2016, 4:37 PM

Sounds good, but really this functionality belongs to sanitizer_common.
May I ask you to move it there? (the flags, the print function, etc).
The actual call to PrintCmdline() you may leave in asan only for now.

Sounds good, but really this functionality belongs to sanitizer_common.
May I ask you to move it there? (the flags, the print function, etc).
The actual call to PrintCmdline() you may leave in asan only for now.

Sure, updating the diff.

ygribov added inline comments.Jan 14 2016, 4:38 AM
lib/sanitizer_common/sanitizer_flags.inc
204 ↗(On Diff #44850)

I'm afraid he'd want implementation for other sanitizers as well...

kcc accepted this revision.Jan 14 2016, 4:37 PM
kcc edited edge metadata.

LGTM with a nit

lib/sanitizer_common/sanitizer_common.cc
495 ↗(On Diff #44850)

either use "argv[i] != nullptr" or just "argv[i]"

lib/sanitizer_common/sanitizer_flags.inc
204 ↗(On Diff #44850)

Nah, that's fine. As soon as some one needs this functionality in other *san they can add it.
But if the code were in asan adding it to other *san would be a bit more complex.

This revision is now accepted and ready to land.Jan 14 2016, 4:37 PM

Thanks, will commit this patch next week. There is one thing I'm concern about: we call PrintCmdline in ~ScopedInErrorReport and this means that we would miss command line in case of we have nested bugs (here desctructor is never called, right?). Is there any reasonable way to handle this situation (perhaps move PrintCmdline to ScopedInErrorReport constructor)?

This revision was automatically updated to reflect the committed changes.