On Thu, Apr 20, 2017 at 10:20 AM, 'Dmitry Vyukov' via address-sanitizer <[email protected]> wrote: > On Thu, Apr 20, 2017 at 11:11 AM, evgeny777 <[email protected]> wrote: >> Thanks for clarifying it, Dmitry. >> >> Here is piece of report I get: >> >> ==18244==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x60200000001a at pc 0x0000005a9cad bp 0x7ffc10528760 sp 0x7ffc10528740 >> WRITE of size 1 at 0x60200000001a thread T0 >> #0 0x5a9cac (/home/evgeny/work/linker_scripts/asan/asan+0x5a9cac) >> #1 0x7f310488082f (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) >> #2 0x419498 (/home/evgeny/work/linker_scripts/asan/asan+0x419498) >> >> .... >> >> Below is the piece of disassembly of main : >> >> ..... >> 0x5a9ca8 <+136>: callq 0x56d9d0 ; >> ::__asan_report_store1(__sanitizer::uptr) at asan_rtl.cc:136 >> 0x5a9cad <+141>: xorl %eax, %eax >> ..... >> >> As you may noticed 0x5a9cac == (0x5a9cad - 1) > > > I think tsan prints unmodified PC and we should do the same in asan. > This also reliefs us from figuring out correct instruction length on > ARM/thumb/etc as nobody sees the modified PC.
Hm, the unmodified PC will make symbolized stacktraces less readable. What's the problem with "-1"? Addr2line and other bintools work fine with it. >> On Thursday, April 20, 2017 at 12:01:25 PM UTC+3, Dmitry Vyukov wrote: >>> >>> On Thu, Apr 20, 2017 at 10:44 AM, evgeny777 <[email protected]> wrote: >>> > I noticed that GetPreviousInstructionPc() function returns 'pc - 1' for >>> > both >>> > arm32 and arm64. >>> > This causes odd addresses to appear in stack traces, which is nonsense, >>> > as >>> > both arm32/64 instructions >>> > have 4 byte size and alignment. >>> > >>> > The x86 and x86_64 cases are even more confusing, because instruction >>> > length >>> > is not constant. What exactly this 'pc - 1' is expected to return? >>> > >>> > But even if one is able to get previous instruction address correctly he >>> > may >>> > still get confusing results. In case some instruction triggers >>> > hardware exception, its address will go to ASAN stack trace (via >>> > SlowUnwindStackWithContext). Returning address of previous instruction >>> > in such case can be extremely confusing. >>> > >>> > Is there any point in using this function? >>> >>> Hi, >>> >>> Yes, there is a very bold point in using this function. >>> Typically top frame PC is obtained with __builtin_return_address, >>> which means that it points to the next instruction after the call. And >>> we need to obtain debug info associated with the call instruction. To >>> achieve that we subtract 1 from PC. All symbolization code that we've >>> seen is fine with PC pointing into a middle of an instruction. >>> >>> Now, if we print pc-1 in reports (do we?), then it's a bug. We need to >>> print unaltered PC in reports. >>> >>> Re hardware exceptions. This needs to be fixed. A trivial change would >>> be to add 1 to PCs pointing to faulting instruction. Then >>> GetPreviousInstructionPc will offset this and we get correct debug >>> info. However, then we will print incorrect PC in report. So a proper >>> fix would be to augment all stack traces with a flag saying if top PC >>> needs to be adjusted during symbolization or not. >> >> -- >> 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. -- 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.
