ASan allows incorrect reordering of memory accesses

[GoogleCodeExporter]

This is a piece of Chromium code on Mac:

(gdb) disas $eip $eip+0x20
Dump of assembler code from 0x5e62b97 to 0x5e62bb7:
0x05e62b97 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+439>:  
mov    0x1c(%esp),%eax
0x05e62b9b <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+443>:  
lea    0x7006f69(%eax),%eax
0x05e62ba1 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+449>:  
mov    %eax,%ecx
0x05e62ba3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+451>:  
shr    $0x3,%ecx
0x05e62ba6 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+454>:  
mov    0x20000000(%ecx),%cl
0x05e62bac <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+460>:  
mov    0x1c0(%esp),%edx
0x05e62bb3 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+467>:  
test   %cl,%cl
0x05e62bb5 <_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+469>:  
je     0x5e62bc0 
<_ZN27ChromeBrowserMainPartsPosix24PostMainMessageLoopStartEv+480>
End of assembler dump.

Note that the access to the original memory location (0x1c0(%esp)) occurs 
before the shadow value is actually tested.
Such bugs may potentially cause the program to crash before the error is 
reported (if we're accessing an unmapped region)

Dima suspects this is because we're passing the result of ptrtoint() to the 
reporting function, thus the compiler does not notice that the pointer escapes.

Original issue reported on code.google.com by ramosian.glider@gmail.com on 7 Feb 2012 at 11:14

[GoogleCodeExporter]

How did you find it? Do you have a source reproducer? 

Original comment by konstant...@gmail.com on 7 Feb 2012 at 5:48

[GoogleCodeExporter]

I was just debugging a (non-existing) hang in Chrome.
I have a repro of ~300 lines that produces almost the same code:

     1b7:       8b 44 24 1c             mov    0x1c(%esp),%eax
     1bb:       8d 80 69 35 02 00       lea    0x23569(%eax),%eax
     1c1:       89 c1                   mov    %eax,%ecx
     1c3:       c1 e9 03                shr    $0x3,%ecx
     1c6:       8a 89 00 00 00 20       mov    0x20000000(%ecx),%cl
     1cc:       8b 94 24 c0 01 00 00    mov    0x1c0(%esp),%edx

, which corresponds to the following assembly:

Ltmp14:
LBB0_3:                                 ## %if.else
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  .loc  2 214 0                 ## browser.ii:214:0
  movl  %esi, %eax
  shrl  $3, %eax
  movb  536870912(%eax), %al
  testb %al, %al
  jne LBB0_32
LBB0_4:
  ##DEBUG_VALUE: PostMainMessageLoopStart:this <- EBP+4294967295
  movl  28(%esp), %eax          ## 4-byte Reload
  leal  __ZN12_GLOBAL__N_123g_shutdown_pipe_read_fdE-L0$pb(%eax), %eax
  movl  %eax, %ecx
  shrl  $3, %ecx
  movb  536870912(%ecx), %cl
  movl  448(%esp), %edx
Ltmp15:
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: ShutdownDetector:shutdown_fd <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  ##DEBUG_VALUE: CheckNEImpl:v1 <- EDX+0 
  testb %cl, %cl
  je  LBB0_6

But I'm not completely sure now that "movb  536870912(%ecx), %cl" and "movl  
448(%esp), %edx" access the shadow and the client memory for the same address.

Original comment by ramosian.glider@gmail.com on 8 Feb 2012 at 9:20

[GoogleCodeExporter]

So, there is not bug here, right? 

Original comment by konstant...@gmail.com on 24 Feb 2012 at 10:56

• Changed state: Invalid

[GoogleCodeExporter]

Not sure yet. Let us leave this as an invalid bug, but keep in mind that we may 
miss  a bug someday because of this.

Original comment by ramosian.glider@gmail.com on 28 Feb 2012 at 11:04