Open GoogleCodeExporter opened 9 years ago
Do you have a Valgrind-like notion of suppressions? I think matching the stack
just before reporting the error is the right thing to do.
Original comment by ramosian.glider@gmail.com
on 3 Aug 2012 at 8:26
+1 to glider@,
I think we should add general suppression support to DRASan (or DR itself?)
rather than doing something ad-hoc.
Also, I'm afraid we'll have to replace str*/mem* functions similiar to what
Valgrind and Dr.Memory and TSan do. Yes, this sucks :(
Original comment by timurrrr@google.com
on 3 Aug 2012 at 8:51
str*/mem* are already replaced by asan. This is inlined, so we can't really
replace it. :(
I don't want to add suppression support because it will be super unreliable,
but I think we have to eventually. This library is built without
-fno-omit-frame-pointer, so I will need to implement a shadow callstack in
order to have reliable callstack walking. The user will user have to install
symbols, or we have to rely on the nearest guy in .dynsym and have weird
symbols that change from system to system.
This is all crappy, but, I think unavoidable.
Shadow callstacks are also useful to drmemory, so this is probably worth doing
as a DR extension so we can reuse it. Currently in drmemory we have a whole
pile of interesting heuristics, but we keep having problems with finnicky
Windows system libraries.
Original comment by rnk@google.com
on 3 Aug 2012 at 2:28
Oh, this really sucks...
> str*/mem* are already replaced by asan.
Yeah, I always forget that on Linux you have the same strlen for all the
libraries in the process rather than a copy for each library.
> This is inlined, so we can't really replace it. :(
> This library is built without -fno-omit-frame-pointer
Is it the same problem like you've observed under Valgrind? Or was it Lei?..
Is there any way to use a different build of the library? Probably we
can/should/must just rebuild the library with "clang -faddress-sanitizer" ?
Original comment by timurrrr@google.com
on 3 Aug 2012 at 4:38
That stack trace looks very familiar. It happens in memcheck as well.
Original comment by thes...@google.com
on 3 Aug 2012 at 4:43
Timur: one cannot simply rebuild every library with ASan, this is the reason
for which we need the dynamic instrumentation.
Reid: how did you get that gdb stack? Did you install additional symbols or was
the .eh_frame section enough to unwind the stack (I think the latter should be
true)?
Original comment by ramosian.glider@gmail.com
on 3 Aug 2012 at 4:46
glider: yes, but rebuilding just fontconfig is much easier than re-building
everything including closed-source libraries
Original comment by timurrrr@google.com
on 3 Aug 2012 at 4:50
Yeah, if you search, you can find similar examples of this coming up as an
uninit read around the web.
I got the stack trace with gdb by installing symbols. I assume it used
.eh_frame/.debug_unwind to unwind.
I'm more inclined to implement a shadow callstack than to parse .eh_frame
because the shadow callstack is portable to Windows.
For now I just added libfontconfig.so to the list of libs for which we don't
instrument reads. Overreads are less serious anyway.
Original comment by rnk@google.com
on 3 Aug 2012 at 5:23
> I'm more inclined to implement a shadow callstack
Only for the dynamic libs or for the main binary too?
Original comment by timurrrr@google.com
on 3 Aug 2012 at 6:04
Hm, I hadn't thought hard enough about it. I think we can probably still get
away without instrumenting the main binary. When we want to turn the shadow
stack into a full callstack, every time the retaddr on the stack doesn't match
the next shadow frame, we can fall back onto a frame pointer walk for a few
frames until it synchs up.
The hard parts with the shadow callstack are how do you get back on track after
a longjmp or exception, or even more crazy, stack switching and user space
threads. Probably can't do that without annotations.
Original comment by rnk@google.com
on 3 Aug 2012 at 7:24
I thought maintaining the shadow callstack adds some extra slowdown which might
be large enough compared to the usual ASan slowdown?
Original comment by timurrrr@google.com
on 4 Aug 2012 at 8:06
I don't know what the slowdown will be until I implement it. :) Maybe it
could be an off-by-default option, so if you get bad stacks, you rerun with it,
and get good stacks.
Original comment by rnk@google.com
on 4 Aug 2012 at 12:58
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:05
Adding Project:AddressSanitizer as part of GitHub migration.
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:06
Original issue reported on code.google.com by
rnk@google.com
on 2 Aug 2012 at 8:05