+tetra2005
On Wed, Sep 24, 2014 at 4:31 PM, Kuba Brecka <[email protected]> wrote: > Hi, > > I'm trying to explore the possibilities of extending ASan to be able to > continue execution after an error is found and a report printed out. I > understand that the fact that ASan is currently aborting/exiting on a report > is totally intentional and that there are some good reasons for it, e.g. > that it's not safe to continue because the memory is corrupted, or that the > UnreachableInst/doesNotReturn play an important role for optimizations. > > However, I believe that there may be some valid reasons to allow continuing > program execution, like when there's a bug in a system library. This can > easily happen even when this library itself is not instrumented, due to > wrappers/interceptors affecting system libraries as well. So doing something > like... > > a = malloc(15); > memset(a, 0, 16); > > ...in a system library would get caught by ASan, and it's definitely a bug. > On the other hand, in this specific case, without ASan, this alone would > (almost certainly) never crash or cause *real* memory corruption, since > malloc allocates 16 bytes anyway. We want to learn about the bug (to be able > to fix it), but I think we also want to be able to continue using ASan > before a new version of the library is shipped with an OS update. > > I am mainly interested in wrappers/interceptors only, because the reports > invoked by instrumentation cannot happen in a library function (since it's > not instrumented) and if a bug in a library triggers a report to be produced > in user's instrumented code, he can blacklist that function or use > __attribute__((no_sanitize_address)). It seems to me it should be possible > to modify the error reporting (in the wrappers only) not to be fatal, and if > that decision whether to abort or not (let's say via a suppression list) is > done only in the case when a poisoned memory access is detected, it > shouldn't have any significant performance hit. > > I noticed that there is an issue suppression mechanism in ThreadSanitizer > and I'm aware that the circumstances for this feature in TSan are different. > However, I'd still like to discuss the possibilities and opinions on this > topic. > > Thank you for any feedback! > > Kuba > > -- > You received this message because you are subscribed to the Google Groups > "address-sanitizer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
