Open ramosian-glider 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.
Reported by ramosian.glider
on 2012-08-03 08:26:47
+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 :(
Reported by timurrrr@google.com
on 2012-08-03 08:51:03
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.
Reported by rnk@google.com
on 2012-08-03 14:28:42
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" ?
Reported by timurrrr@google.com
on 2012-08-03 16:38:56
That stack trace looks very familiar. It happens in memcheck as well.
Reported by thestig@google.com
on 2012-08-03 16:43:57
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)?
Reported by ramosian.glider
on 2012-08-03 16:46:55
glider: yes, but rebuilding just fontconfig is much easier than re-building everything
including closed-source libraries
Reported by timurrrr@google.com
on 2012-08-03 16:50:08
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.
Reported by rnk@google.com
on 2012-08-03 17:23:22
> I'm more inclined to implement a shadow callstack
Only for the dynamic libs or for the main binary too?
Reported by timurrrr@google.com
on 2012-08-03 18:04:11
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.
Reported by rnk@google.com
on 2012-08-03 19:24:40
I thought maintaining the shadow callstack adds some extra slowdown which might be large
enough compared to the usual ASan slowdown?
Reported by timurrrr@google.com
on 2012-08-04 08:06:10
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.
Reported by rnk@google.com
on 2012-08-04 12:58:45
Reported by ramosian.glider
on 2015-07-30 09:05:30
Adding Project:AddressSanitizer as part of GitHub migration.
Reported by ramosian.glider
on 2015-07-30 09:06:55
Originally reported on Google Code with ID 97
Reported by
rnk@google.com
on 2012-08-02 20:05:34