Closed Bug 948050 Opened 11 years ago Closed 10 years ago

Intermittent testGlobalAsProto.js | --ion-eager --ion-check-range-analysis --no-sse3

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: RyanVM, Unassigned)

References

Details

(Keywords: intermittent-failure)

https://tbpl.mozilla.org/php/getParsedLog.php?id=31686048&tree=Mozilla-Inbound

Linux x86-64 mozilla-inbound asan build on 2013-12-09 07:16:44 PST for push 9658dbcf4cd7
slave: bld-linux64-ec2-301

TEST-UNEXPECTED-FAIL | js/src/jit-test/tests/basic/testGlobalAsProto.js | --ion-eager --ion-check-range-analysis --no-sse3
INFO exit-status     : 1
INFO timed-out       : False
INFO stdout          > 
INFO stderr         2> =================================================================
INFO stderr         2> ==24843==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f6faaffec20 at pc 0x7f6fb012a2c9 bp 0x7f6faaffebd0 sp 0x7f6faaffebc8
INFO stderr         2> WRITE of size 112 at 0x7f6faaffec20 thread T1
INFO stderr         2> #0 0x7f6fb012a2c8 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x592c8)
INFO stderr         2> #1 0x7f6fb0129eb7 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x58eb7)
INFO stderr         2> #2 0x7f6fb013f942 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x6e942)
INFO stderr         2> #3 0x4c2363 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/js/src/shell/js+0x4c2363)
INFO stderr         2> #4 0x7f6fb036f7f0 (/lib64/libpthread.so.0+0x77f0)
INFO stderr         2> #5 0x7f6faee5a92c (/lib64/libc.so.6+0xe592c)
INFO stderr         2> Address 0x7f6faaffec20 is located in stack of thread T1 at offset 32 in frame
INFO stderr         2> #0 0x7f6fb0129f0f (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x58f0f)
INFO stderr         2> This frame has 1 object(s):
INFO stderr         2> [32, 144) 'post'
INFO stderr         2> HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
INFO stderr         2> (longjmp and C++ exceptions *are* supported)
INFO stderr         2> Thread T1 created by T0 here:
INFO stderr         2> #0 0x4acc61 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/js/src/shell/js+0x4acc61)
INFO stderr         2> #1 0x7f6fb013bbe5 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x6abe5)
INFO stderr         2> #2 0x7f6fb013b737 (/builds/slave/m-in-l64-asan-0000000000000000/build/obj-firefox/dist/bin/libnspr4.so+0x6a737)
INFO stderr         2> Shadow bytes around the buggy address:
INFO stderr         2> 0x0fee755f7d30: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7d40: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7d50: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7d60: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7d70: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> =>0x0fee755f7d80: f1 f1 f1 f1[f5]bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7d90: 00 00 f4 f4 f3 f3 f3 f3 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7da0: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7db0: bb 73 bc 24 f5 bc 3d e4 f1 f1 f1 f1 00 f4 f4 f4
INFO stderr         2> 0x0fee755f7dc0: f3 f3 f3 f3 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> 0x0fee755f7dd0: bb 73 bc 24 f5 bc 3d e4 27 4d df 00 3d 81 30 8a
INFO stderr         2> Shadow byte legend (one shadow byte represents 8 application bytes):
INFO stderr         2> Addressable:           00
INFO stderr         2> Partially addressable: 01 02 03 04 05 06 07
INFO stderr         2> Heap left redzone:     fa
INFO stderr         2> Heap right redzone:    fb
INFO stderr         2> Freed heap region:     fd
INFO stderr         2> Stack left redzone:    f1
INFO stderr         2> Stack mid redzone:     f2
INFO stderr         2> Stack right redzone:   f3
INFO stderr         2> Stack partial redzone: f4
INFO stderr         2> Stack after return:    f5
INFO stderr         2> Stack use after scope: f8
INFO stderr         2> Global redzone:        f9
INFO stderr         2> Global init order:     f6
INFO stderr         2> Poisoned by user:      f7
INFO stderr         2> ASan internal:         fe
INFO stderr         2> ==24843==ABORTING
INFO stderr         2>
Depends on: 948171
The trace is pointing at some problem with NSPR:

==24843==ERROR: AddressSanitizer: stack-use-after-return on address 0x7f6faaffec20 at pc 0x7f6fb012a2c9 bp 0x7f6faaffebd0 sp 0x7f6faaffebc8
WRITE of size 112 at 0x7f6faaffec20 thread T1
#0 0x7f6fb012a2c8 in pt_PostNotifies nsprpub/pr/src/pthreads/ptsynch.c:80
#1 0x7f6fb0129eb7 in PR_Unlock nsprpub/pr/src/pthreads/ptsynch.c:208
#2 0x7f6fb013f942 in _pt_root nsprpub/pr/src/pthreads/ptthread.c:159
#3 0x4c2363 in ThreadStart _asan_rtl_
#4 0x7f6fb036f7f0 in 
#5 0x7f6faee5a92c in  
Address 0x7f6faaffec20 is located in stack of thread T1 at offset 32 in frame
#0 0x7f6fb0129f0f in pt_PostNotifies nsprpub/pr/src/pthreads/ptsynch.c:70
This frame has 1 object(s):
[32, 144) 'post'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
Thread T1 created by T0 here:
#0 0x4acc61 in __interceptor_pthread_create _asan_rtl_
#1 0x7f6fb013bbe5 in _PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:445
#2 0x7f6fb013b737 in PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:528
Ok, so I talked to kcc about this trace and he said several things:

1) The report itself is broken. The shadow memory printed in the trace is garbage, some of the data there will never be written by ASan.

2) The "use-after-return" is bogus, ASan just reports that because it hits 'f5' (uar magic) in the shadow memory, but this is a random thing.

3) Something is writing into the shadow memory (causing a memory corruption). ASan-instrumented code cannot write there, so this is either a) assembly code b) uninstrumented code or c) another process with shared memory.

I assume that variant b), the uninstrumented code, is most likely. More precisely, jitted code is not instrumented, so if jitted code is wrong and starts writing into random memory, then it can also hit the shadow memory and cause such a failure. That theory is also very likely because this is a jit-test and it's running with --ion-eager.
Intermittent failure not seen for >3 months; filter on mass-intermittent-wfm-20140812.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.