wasm/streaming-trap-location failing on GC stress |
||||
Issue descriptionhttps://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15470/steps/Bisect%209dc6dd86.Retry/logs/streaming-trap-location Test: mjsunit/wasm/streaming-trap-location Flags: --stress-opt --always-opt Command: /b/s/w/ir/out/Debug/d8 --test --random-seed=2140216864 --stress-opt --always-opt --nohard-abort --enable-slow-asserts --verify-heap --wasm-test-streaming --wasm-async-compilation --expose-wasm /b/s/w/ir/test/mjsunit/wasm/streaming-trap-location.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation Build environment: gn_args: is_component_build = true is_debug = true target_cpu = "x64" use_goma = true v8_embed_script = "test/mjsunit/mjsunit.js" v8_enable_backtrace = true v8_enable_slow_dchecks = true v8_test_isolation_mode = "prepare" Run #1 Exit code: -6 Result: FAIL Expected outcomes: PASS Duration: 00:00:471 Stdout: ============ Stress 1/2 ============ Stderr: Received signal 6 ==== C stack trace =============================== [0x7f48bd35a755] [0x7f48bcf48330] [0x7f48bb3a7c37] [0x7f48bb3ab028] [0x7f48bccca2f0] [0x7f48bccca192] [0x7f48bcd0090d] [0x7f48bc7cd23d] [0x7f48bc7cd483] [0x7f48bc7cdc5b] [0x7f48bc7ea294] [0x7f48bc7e8c11] [0x7f48bc779a7e] [0x7f48bc78e5de] [0x7f48bc78eb5b] [0x7f48bc904bf6] [0x7f48bc905afd] [0x7f48bc969d4c] [0x7f48bc96a5d1] [0x7f48bc785cfd] [0x7f48bcc8cc6c] [0x39a7c8e847e4] [end of stack trace]
,
Oct 11 2017
We did some analysis here. To reproduce: 1. Checkout revision f3c8da56e91c5731b7b821e8d53bd25932cdd057. 2. Build a debug build with custom snapshot, gn args: is_component_build = true is_debug = true target_cpu = "x64" use_goma = true v8_embed_script = "test/mjsunit/mjsunit.js" v8_enable_backtrace = true v8_enable_slow_dchecks = true v8_test_isolation_mode = "prepare" 3. Execute: d8 --test --random-seed=2140216864 --stress-opt --always-opt --nohard-abort --enable-slow-asserts --verify-heap --wasm-test-streaming --wasm-async-compilation --expose-wasm test/mjsunit/wasm/streaming-trap-location.js --gc-interval=500 --stress-compaction --concurrent-recompilation-queue-length=64 --concurrent-recompilation-delay=500 --concurrent-recompilation --print-wasm-code 4. Run in gdb. What happens: A first instance is created, throws because of unreachable, then loads from an invalid address (handled by the trap handler), this all works. Then a second instance is created, throws because of unreachable, and this segfaults. The stack trace: #0 0x00007fda3a5c3c37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007fda3a5c7028 in __GI_abort () at abort.c:89 #2 0x00007fda3bee1a00 in v8::internal::trap_handler::MetadataLock::MetadataLock (this=<optimized out>) at ../../src/trap-handler/handler-shared.cc:43 #3 0x00007fda3bee18a2 in v8::internal::trap_handler::ReleaseHandlerData (index=0) at ../../src/trap-handler/handler-outside.cc:231 #4 0x00007fda3bf1801d in v8::internal::wasm::InstanceFinalizer (data=...) at ../../src/wasm/module-compiler.cc:409 #5 0x00007fda3b9e671d in v8::internal::GlobalHandles::Node::PostGarbageCollectionProcessing (this=0x5605b3003860, isolate=0x5605b2f9b0c0) at ../../src/global-handles.cc:321 #6 0x00007fda3b9e6963 in v8::internal::GlobalHandles::PostMarkSweepProcessing (this=0x5605b2fbaa20, initial_post_gc_processing_count=9) at ../../src/global-handles.cc:767 #7 0x00007fda3b9e713b in v8::internal::GlobalHandles::PostGarbageCollectionProcessing (this=0x5605b2fbaa20, collector=<optimized out>, gc_callback_flags=<optimized out>) at ../../src/global-handles.cc:878 #8 0x00007fda3ba03464 in v8::internal::Heap::PerformGarbageCollection (this=0x5605b2f9b0e0, collector=<optimized out>, gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:1581 #9 0x00007fda3ba01de1 in v8::internal::Heap::CollectGarbage (this=0x5605b2f9b0e0, space=<optimized out>, gc_reason=<optimized out>, gc_callback_flags=v8::kNoGCCallbackFlags) at ../../src/heap/heap.cc:1216 #10 0x00007fda3b99222e in v8::internal::Factory::NewJSObjectFromMap (this=0x5605b2f9b0c0, map=..., pretenure=v8::internal::NOT_TENURED, allocation_site=...) at ../../src/factory.cc:1940 #11 0x00007fda3b9a6c1e in v8::internal::Factory::NewJSArray (this=0x5605b2f9b0c0, elements_kind=<optimized out>, pretenure=v8::internal::NOT_TENURED) at ../../src/factory.cc:1967 #12 0x00007fda3b9a719b in v8::internal::Factory::NewJSArrayWithElements (this=0x5605b2f9b0c0, elements=..., elements_kind=v8::internal::HOLEY_ELEMENTS, length=36, pretenure=v8::internal::NOT_TENURED) at ../../src/factory.cc:1984 #13 0x00007fda3bb1d3b6 in NewJSArrayWithElements (this=<optimized out>, elements_kind=v8::internal::HOLEY_ELEMENTS, pretenure=v8::internal::NOT_TENURED, elements=...) at ../../src/factory-inl.h:115 #14 v8::internal::Isolate::CaptureSimpleStackTrace (this=0x5605b2f9b0c0, error_object=..., mode=<optimized out>, caller=...) at ../../src/isolate.cc:620 #15 0x00007fda3bb1e2bd in v8::internal::Isolate::CaptureAndSetSimpleStackTrace (this=0x5605b2f9b0c0, error_object=..., mode=(v8::internal::SKIP_NONE | unknown: 4), caller=...) at ../../src/isolate.cc:644 #16 0x00007fda3bb821fc in v8::internal::ErrorUtils::Construct (isolate=0x5605b2f9b0c0, target=..., new_target=..., message=..., mode=v8::internal::SKIP_NONE, caller=..., suppress_detailed_trace=<optimized out>) at ../../src/messages.cc:1129 #17 0x00007fda3bb82a81 in v8::internal::ErrorUtils::MakeGenericError (isolate=0x5605b2f9b0c0, constructor=..., template_index=301, arg0=..., arg1=..., arg2=..., mode=<optimized out>) at ../../src/messages.cc:1254 #18 0x00007fda3b99e33d in v8::internal::Factory::NewError (this=0x5605b2f9b0c0, constructor=..., template_index=v8::internal::MessageTemplate::kUnsupported, arg0=..., arg1=..., arg2=...) at ../../src/factory.cc:1442 #19 0x00007fda3bea434c in v8::internal::ThrowRuntimeError (isolate=0x5605b2f9b0c0, message_id=301, byte_offset=0, patch_source_position=false) at ../../src/runtime/runtime-wasm.cc:66 It crashes because of this code in handler-shared.cc: 41 MetadataLock::MetadataLock() { 42 if (g_thread_in_wasm_code) { 43 abort(); 44 } The "thread in wasm" flag is still set. This is because we do not call the runtime function ThrowRuntimeError directly, but via a builtin. It seems that we do not reset/set the flag at all in this path. WDYT about moving this reset/set logic into the runtime functions we are calling from wasm? That would also reduce code size and compilation time.
,
Oct 11 2017
Proof-of-concept CL: https://chromium-review.googlesource.com/c/v8/v8/+/712597
,
Oct 12 2017
Looks like we are taking the proposed approach.
,
Oct 16 2017
,
Oct 16 2017
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/0738f0f6685ec84daefbb3db5f3328143b96fda1 commit 0738f0f6685ec84daefbb3db5f3328143b96fda1 Author: Clemens Hammacher <clemensh@chromium.org> Date: Mon Oct 16 15:17:29 2017 [wasm] Move "thread in wasm" flag handling out of compiled code Instead of modifying this flag in compiled wasm code, we can just change it in the caller / called code. This saves code space and compilation time and fixes the referenced bug. R=titzer@chromium.org, eholk@chromium.org Bug: chromium:773631 , v8:5277 Change-Id: I095158ac01eecd21a92649a3990e8d7c593db912 Reviewed-on: https://chromium-review.googlesource.com/712597 Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Eric Holk <eholk@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48602} [modify] https://crrev.com/0738f0f6685ec84daefbb3db5f3328143b96fda1/src/compiler/wasm-compiler.cc [modify] https://crrev.com/0738f0f6685ec84daefbb3db5f3328143b96fda1/src/runtime/runtime-wasm.cc [modify] https://crrev.com/0738f0f6685ec84daefbb3db5f3328143b96fda1/src/trap-handler/handler-inside.cc [modify] https://crrev.com/0738f0f6685ec84daefbb3db5f3328143b96fda1/src/wasm/wasm-interpreter.cc
,
Oct 16 2017
,
Aug 16
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/6772b400369fe0251b6b91e258c129717ff30f51 commit 6772b400369fe0251b6b91e258c129717ff30f51 Author: Ben L. Titzer <titzer@chromium.org> Date: Thu Aug 16 14:19:02 2018 [wasm] Enable some disabled WASM tests R=ahaas@chromium.org Bug: chromium:751825 , chromium:773631 Change-Id: I87f6e9859b6adfe46adde7bf08fd16978035aa1f Reviewed-on: https://chromium-review.googlesource.com/1177702 Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55165} [modify] https://crrev.com/6772b400369fe0251b6b91e258c129717ff30f51/test/mjsunit/mjsunit.status |
||||
►
Sign in to add a comment |
||||
Comment 1 by bugdroid1@chromium.org
, Oct 11 2017