[UBSan] stack trace?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[UBSan] stack trace?

Greg Fitzgerald
Is there a way to get the undefined-behavior sanitizer to include
stack traces in their error messages?

Also, I'm sometimes seeing raw addresses where I'd expect to see file
names and line numbers.  Do I need to point this sanitizer to
llvm-symbolizer?  And if so, how?

Thanks,
Greg
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [UBSan] stack trace?

Richard Smith-33
On Thu, Jun 27, 2013 at 1:06 PM, Greg Fitzgerald <[hidden email]> wrote:
> Is there a way to get the undefined-behavior sanitizer to include
> stack traces in their error messages?

Currently, no. Patches would be welcome; compiler-rt already has code
for extracting a backtrace, but it's not hooked into the ubsan
diagnostic mechanism yet. The nontrivial part here is that the
existing sanitizer mechanism hooks into thread creation to determine
the extent of stacks, which we don't really want to do in ubsan (we
try to avoid interjecting any symbols there). Perhaps finding the
region containing the stack pointer in /proc/self/maps would be a
reasonable way to handle that. (compiler-rt also already has a
mechanism to parse that file.)

> Also, I'm sometimes seeing raw addresses where I'd expect to see file
> names and line numbers.  Do I need to point this sanitizer to
> llvm-symbolizer?  And if so, how?

There's not really a good way to do that yet: ubsan doesn't have an
initialization function where we would parse flags. Again, patches
welcome. We should initialize it lazily when the first diagnostic is
issued; a call to ParseCommonFlagsFromString(GetEnv("UBSAN_OPTIONS"))
would be appropriate.

That said, any time it produces an address rather than a file/line is
a missing feature in Clang's instrumentation (it means the
instrumentation didn't emit a source location for the diagnostic), and
this could alternatively be fixed with a Clang change to emit an
appropriate source location with the diagnostic.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev