>Alternately, asan could detect >= 2^47 addresses and report them before the Windows access violation so that we can get an actual address - that would be even better.

rnk@ does this sound doable?

If not, I'm glad to do the alternate solution of implementing it in ClusterFuzz. But the downside to a ClusterFuzz solution is that we couldn't solve issue 901848

+rnk

I suppose we'd have to do it the same way that other post-mortem debugging tools do it, by working it out from the disassembly:
https://github.com/luser/breakpad/commit/c8c0bbcdba178b74db171c21d2c6f4a59efd0131

For ASan instrumented accesses, it's important for the fast path to stay fast, and right now it just looks like this:
  30:	48 89 f8             	mov    %rdi,%rax
  33:	48 c1 e8 03          	shr    $0x3,%rax
  37:	80 b8 00 80 ff 7f 00 	cmpb   $0x0,0x7fff8000(%rax)
  3e:	75 04                	jne    44 <load8+0x14>

There's not much room there to add a test of the top 16 bits.

Typically, when a wild, non-canonical pointer is dereferenced, it's the shadow memory access that faults, which makes debugging that much harder.

ASan doesn't currently have a disassembler, so I think we could implement the suggestion to print a note that a faulting address of 2^64-1 is probably a lie, but finding the true address is probably infeasible. I don't think that feature is enough to motivate integrating an entire x86 disassembler into the asan runtime.

+kcc, eugenis

Available, but no owner or component? Please find a component, as no one will ever find this without one.