symbolize stack traces using code from lldb about address-sanitizer HOT 17 OPEN

Hello, do you have an estimate as to when this will be available?

Nope. We did not start yet, sorry. :( 
If asan_symbolize.py does not work for you, please let us know why (in a 
separate mail or bug)

we need this for tsan as well. 
Dmitry, could you please handle this? 

I've created the lldb symbolizer prototype for tsan:
http://code.google.com/p/data-race-test/source/browse/trunk/v2/tsan/tsan_symboli
ze_lldb_linux.cc
It works. One needs to manually build liblldb.so first.
Several patches are committed to lldb, one still in flight 
(SBTarget::SetModuleLoadAddress() may print spurious warnings, but must 
generally work otherwise).
LLDB does not work with -pie on Linux, reported but not fixed yet.
Symbolizer is unlikely to be separated from LLDB, so we will depend on LLDB if 
take this route.
LLDB is a huge piece of C++ code, so we will need libstdc++ and will have 
recursive interceptors (it calls malloc/etc).

>LLDB does not work with -pie on Linux, reported but not fixed yet.

http://llvm.org/bugs/show_bug.cgi?id=12355

>> and will have recursive interceptors
OMG. Hopefully not. We do not have to symbolize inside malloc.

Also, is it possible to implement the symbolizer as an LD_PRELOAD-able library? 

>>> and will have recursive interceptors
>OMG. Hopefully not. We do not have to symbolize inside malloc.
That was related to tsan.

>Also, is it possible to implement the symbolizer as an LD_PRELOAD-able library?
Generally I do not see any obstacles, however I am not sure whether it will 
work in all our contexts.

Could we make it dlopen()able instead? LD_PRELOAD sounds like a strange choice 
of an interface between 2 libraries, both of which we control.

stdc++ dependency in the rtl is undesirable on Android, but definitely not a 
show stopper.

>> Could we make it dlopen()able instead? 
I think so

> Could we make it dlopen()able instead? LD_PRELOAD sounds like a strange 
choice of an interface between 2 libraries, both of which we control.

Well, currently I have 3 separate source files with different symbolizers 
(null, addr2line, lldb) in tsan. One of them is chosen during build. In every 
context we know which one we need, so it looks fine as is. Do we really need to 
switch symbolizers dynamically?

one reason to chose between null and lldb symbolizers at run-time is that lldb 
symbolizer does not come for free (it has a run-time cost) and we may want to 
produce 
warnings with null symbolizer very fast. 

Then we build with lldb symbolizer and turn off symbolization (but do not 
switch the symbolizer) at runtime.

I wish not to depend on libstc++ by default. 

Issue 134 has been merged into this issue.

Issue 206 has been merged into this issue.

The goal of this issue seems to be changed to "Build isolated non-instrumented 
in-process symbolizer" or so.