Expose __sanitizer_print_stack_trace()?

[GoogleCodeExporter]

When I'm hacking Chrome and need to trace a function call, I can do 
"base::debug::StackTrace().Print()". However, the stack traces produced by 
sanitizer tools are much better, and often I find myself introducing an ASan 
error just to see the stack trace. This is ugly and has the unwanted effect of 
killing the process. Should we perhaps expose an interface function like 
__sanitizer_print_stack_trace()?

Original issue reported on code.google.com by earth...@google.com on 14 Nov 2013 at 6:25

[GoogleCodeExporter]

go for it!

Original comment by konstant...@gmail.com on 15 Nov 2013 at 5:09

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

is this done? 

Original comment by konstant...@gmail.com on 6 Dec 2013 at 11:20

[GoogleCodeExporter]

Currently we only define this function in ASan (which is where I need it). We 
decided to wait until the stack unwinding code is generalized enough that this 
function can be implemented in sanitizer_common, rather than implement it 
separately in each tool. I would keep this open until then.

Original comment by earth...@chromium.org on 6 Dec 2013 at 12:15

[GoogleCodeExporter]

This function is actually super helpful. There's just one problem. Typically 
you would use it something like this:

void Class::Method() {
  fprintf(stderr, "Method() in %p\n", this);
  __sanitizer_print_stack_trace();
  ...
}

But now if I set log_path, the stack traces go in the file and all the 
additional info still goes to stderr. This is pretty much useless.

So now we may need to expose __sanitizer_report() as well.

Original comment by earth...@chromium.org on 12 Dec 2013 at 9:19

[GoogleCodeExporter]

May be even __sanitizer_printf, or have __sanitizer_report accept printf-style 
format string (the limited format parsed by internal Printf).

Original comment by euge...@google.com on 13 Dec 2013 at 8:33

[GoogleCodeExporter]

I think you're over-complicating things. Your use case can be fixed by calling 
__sanitizer_set_report_path("stderr"). Why should we expose sanitizer logging 
machinery to the end-user?

Original comment by samso...@google.com on 13 Dec 2013 at 9:23

[GoogleCodeExporter]

>  Your use case can be fixed by calling __sanitizer_set_report_path("stderr").

In other words, you're suggesting not to use log_path. In Chrome, parsing the 
output of several renderers intermixed in the same log is less than fun.

Original comment by earth...@chromium.org on 13 Dec 2013 at 11:03

[GoogleCodeExporter]

I still find it weird that you essentially use sanitizer runtime for logging. 
This is not its purpose. Another way to fix your example - call 
"fprintf(stderr, "==%d== Method in %p", getpid(), this)); and match pid to log 
produced by sanitizer.

Original comment by samso...@google.com on 13 Dec 2013 at 11:11

[GoogleCodeExporter]

I dunno. Sanitizers are essentially debugging tools, so why not add extra 
debugging functionality.

> Another way to fix your example - call "fprintf(stderr, "==%d== Method in 
%p", getpid(), this)); and match pid to log produced by sanitizer.

This doesn't help in the example above when I want to see which object the 
stack trace is associated with.

Original comment by earth...@chromium.org on 13 Dec 2013 at 1:14

[GoogleCodeExporter]

Sanitizers are small special-purpose tools for detecting certain kinds of 
errors. Anyway, that's just my opinion, let's hear from others. Kostya?

Original comment by samso...@google.com on 13 Dec 2013 at 1:18

[GoogleCodeExporter]

Can you make void __sanitizer_print_stack_trace(const char *fmt, ...)
which will both print whatever you need to print and then print stack trace?
just make sure that __sanitizer_print_stack_trace(0) works too

Original comment by konstant...@gmail.com on 13 Dec 2013 at 1:23

[GoogleCodeExporter]

You don't always want to print the stack trace, sometimes you just need a debug 
print. But you still want to see the debug output of the process as one stream, 
with all the stack traces and without interference from other processes.

I don't *particularly* like the idea of exposing Report() either, but I don't 
see a better way to solve this, and moreover I can't come up with a strong case 
against it.

Original comment by earth...@chromium.org on 13 Dec 2013 at 3:14

[GoogleCodeExporter]

Ping?

Original comment by earth...@google.com on 23 Dec 2013 at 3:22

[GoogleCodeExporter]

maybe __sanitizer_print_stack_trace(int max_frames, const char *fmt, ...) ?
With max_frames==0 this turns into Report.
We need max_frames anyway, because printing large number of frames may 
slowdown the program significantly and thus hide a time-sensitive bug. 

Original comment by konstant...@gmail.com on 24 Dec 2013 at 7:20

[GoogleCodeExporter]

http://llvm.org/viewvc/llvm-project?rev=196302&view=rev added asan 
implementation.
we don't have msan and tsan variants yet.

Original comment by konstant...@gmail.com on 14 May 2014 at 1:53

[GoogleCodeExporter]

Yes, an MSan implementation would be most welcome. I've had to put fake 
uninitialized accesses into Chromium code one too many times...

Original comment by earth...@chromium.org on 14 May 2014 at 4:25

[GoogleCodeExporter]

MSan implementation was added a while ago.
http://llvm.org/viewvc/llvm-project?view=revision&revision=221469 adds TSan 
implementation.

Original comment by samso...@chromium.org on 6 Nov 2014 at 6:55

[GoogleCodeExporter]

Original comment by samso...@google.com on 6 Nov 2014 at 6:55

• Changed state: Fixed