Landed one more time as https://code.google.com/p/v8/source/detail?r=16629
On Tue, Sep 10, 2013 at 10:34 AM, Rafael Weinstein <[email protected]>wrote: > Michael has landed: https://code.google.com/p/v8/source/detail?r=16623 > > This should unblock this patch (I've verified locally that GC stress no > longer crashes). > > Adam, can you please attempt to re-land? > > > On Thu, Sep 5, 2013 at 12:35 PM, Rafael Weinstein <[email protected]>wrote: > >> Note that I am now only seeing the crash under GC stress: >> >> /Volumes/src/v8/out/ia32.debug/d8 --test --nocrankshaft >> --nobreak-on-abort --nodead-code-elimination --nofold-constants >> --enable-slow-asserts --debug-code --verify-heap --harmony-observation >> --harmony-proxies --harmony-collections --harmony-symbols >> --allow-natives-syntax /Volumes/src/v8/test/mjsunit/mjsunit.js >> /Volumes/src/v8/test/mjsunit/harmony/object-observe.js --gc-interval=500 >> --stress-compaction --concurrent-recompilation-queue-length=64 >> --concurrent-recompilation-delay=500 --concurrent-recompilation >> >> But it appears to be exactly the same stack trace. >> >> >> On Wed, Sep 4, 2013 at 6:18 AM, Rafael Weinstein <[email protected]>wrote: >> >>> Any progress on this? >>> >>> >>> On Thu, Aug 29, 2013 at 11:09 AM, Rafael Weinstein >>> <[email protected]>wrote: >>> >>>> Thanks much! >>>> >>>> >>>> On Thu, Aug 29, 2013 at 11:07 AM, Michael Starzinger < >>>> [email protected]> wrote: >>>> >>>>> Hey Rafael! >>>>> >>>>> I already have a strong suspicion what is causing this. It is another >>>>> instance of where we are calling from unhandlified into handlified code, >>>>> but keep using stale handles. Toon and I are handlifying everything around >>>>> JSObject::SetProperty right now, because it keeps biting us too often by >>>>> now. I can reproduce the issue you mentioned in your mail and will >>>>> probably >>>>> have a fix for you tomorrow. >>>>> >>>>> Best regards, >>>>> Michael >>>>> >>>>> >>>>> On Thu, Aug 29, 2013 at 7:19 PM, Rafael Weinstein >>>>> <[email protected]>wrote: >>>>> >>>>>> It looks like maybe in setting the value in the WeakMap, a hash is >>>>>> created for the key value, but when it gets set, the resulting object's >>>>>> map >>>>>> is bad memory. >>>>>> >>>>>> Michael, any chance you can look at this? >>>>>> >>>>>> >>>>>> On Wed, Aug 28, 2013 at 3:21 PM, Rafael Weinstein <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> So I've been able to narrow this down and make it more reproducible, >>>>>>> but I'm out of my depth trying to figure out what's going on. It's >>>>>>> crashing >>>>>>> while trying to set a value in WeakMap (the map appears to be trashed). >>>>>>> >>>>>>> -Apply the reverted patch: >>>>>>> https://code.google.com/p/v8/source/detail?r=16343 >>>>>>> -Use a reduced object-observe.js test (attached) >>>>>>> -Compile x64.debug >>>>>>> -Run with standard test flags: --test --nocrankshaft >>>>>>> --nobreak-on-abort --nodead-code-elimination --nofold-constants >>>>>>> --enable-slow-asserts --debug-code --verify-heap --harmony-observation >>>>>>> --harmony-proxies --harmony-collections --harmony-symbols >>>>>>> --allow-natives-syntax >>>>>>> >>>>>>> I get: >>>>>>> >>>>>>> Program received signal EXC_BAD_ACCESS, Could not access memory. >>>>>>> Reason: 13 at address: 0x0000000000000000 >>>>>>> >>>>>>> here: >>>>>>> >>>>>>> #0 v8::internal::Map::instance_type (this=0x1beefdad0beefdaf) at >>>>>>> objects-inl.h:3467 >>>>>>> #1 0x0000000100013984 in v8::internal::Object::IsOddball >>>>>>> (this=0x21bd78effb21) at objects-inl.h:674 >>>>>>> #2 0x0000000100043729 in v8::internal::Object::IsUndefined >>>>>>> (this=0x21bd78effb21) at objects-inl.h:856 >>>>>>> #3 0x00000001002edf7e in v8::internal::JSObject::GetIdentityHash >>>>>>> (this=0x21bd78effb21, flag=v8::internal::ALLOW_CREATION) at >>>>>>> ../src/objects.cc:4742 >>>>>>> #4 0x000000010031acc6 in v8::internal::JSReceiver::GetIdentityHash >>>>>>> (this=0x21bd78effb21, flag=v8::internal::ALLOW_CREATION) at >>>>>>> objects-inl.h:5820 >>>>>>> #5 0x00000001002da672 in v8::internal::Object::GetHash >>>>>>> (this=0x21bd78effb21, flag=v8::internal::ALLOW_CREATION) at >>>>>>> ../src/objects.cc:1018 >>>>>>> #6 0x00000001002eecf3 in v8::internal::ObjectHashTable::Put >>>>>>> (this=0x5a9e5c5b9f1, key=0x21bd78effb21, value=0x21bd78efff91) at >>>>>>> ../src/objects.cc:15402 >>>>>>> #7 0x000000010015cfdf in v8::internal::PutIntoObjectHashTable >>>>>>> (table={location_ = 0x1018575f8}, key={location_ = 0x7fff5fbfee98}, >>>>>>> value={location_ = 0x1018575f0}) at ../src/handles.cc:862 >>>>>>> #8 0x00000001003834e9 in __RT_impl_Runtime_WeakCollectionSet >>>>>>> (args={<v8::internal::Embedded> = {<No data fields>}, length_ = 3, >>>>>>> arguments_ = 0x7fff5fbfeea0}, isolate=0x101803200) at >>>>>>> ../src/runtime.cc:1565 >>>>>>> #9 0x0000000100383386 in v8::internal::Runtime_WeakCollectionSet >>>>>>> (args_length=3, args_object=0x7fff5fbfeea0, isolate=0x101803200) at >>>>>>> ../src/runtime.cc:1557 >>>>>>> #10 0x00000975806072ce in ?? () >>>>>>> #11 0x0000097580649962 in ?? () >>>>>>> #12 0x00000975806496a2 in ?? () >>>>>>> #13 0x0000097580648ed9 in ?? () >>>>>>> #14 0x0000097580610634 in ?? () >>>>>>> #15 0x00000975806456f3 in ?? () >>>>>>> #16 0x0000097580642764 in ?? () >>>>>>> #17 0x000009758062e924 in ?? () >>>>>>> #18 0x0000097580619817 in ?? () >>>>>>> #19 0x00000001001072c9 in Invoke (is_construct=false, >>>>>>> function={location_ = 0x1018575d0}, receiver={location_ = 0x1018575e0}, >>>>>>> argc=0, args=0x0, has_pending_exception=0x7fff5fbff337) at >>>>>>> ../src/execution.cc:119 >>>>>>> #20 0x0000000100106d9a in v8::internal::Execution::Call >>>>>>> (callable={location_ = 0x1018575d0}, receiver={location_ = 0x1018575e0}, >>>>>>> argc=0, argv=0x0, pending_exception=0x7fff5fbff337, >>>>>>> convert_receiver=false) >>>>>>> at ../src/execution.cc:182 >>>>>>> #21 0x0000000100025831 in v8::Script::Run (this=0x1018575a8) at >>>>>>> ../src/api.cc:1848 >>>>>>> #22 0x0000000100000f6e in v8::Shell::ExecuteString >>>>>>> (isolate=0x101803200, source={val_ = 0x1018575a0}, name={val_ = >>>>>>> 0x101857598}, print_result=false, report_exceptions=true) at >>>>>>> ../src/d8.cc:216 >>>>>>> #23 0x0000000100005ca4 in v8::SourceGroup::Execute >>>>>>> (this=0x101003d78, isolate=0x101803200) at ../src/d8.cc:1257 >>>>>>> #24 0x000000010000695e in v8::Shell::RunMain (isolate=0x101803200, >>>>>>> argc=16, argv=0x7fff5fbff8f0) at ../src/d8.cc:1517 >>>>>>> #25 0x0000000100006ded in v8::Shell::Main (argc=16, >>>>>>> argv=0x7fff5fbff8f0) at ../src/d8.cc:1698 >>>>>>> #26 0x000000010000be32 in main (argc=16, argv=0x7fff5fbff8f0) at >>>>>>> ../src/d8.cc:173 >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 27, 2013 at 2:33 AM, <[email protected]> wrote: >>>>>>> >>>>>>>> On 2013/08/26 23:11:33, adamk - vacation until sept 3 wrote: >>>>>>>> >>>>>>>>> Tried runnings tests with >>>>>>>>> >>>>>>>> >>>>>>>> "--extra-flags --noenable-sse2" >>>>>>>>> >>>>>>>> >>>>>>>> which is what the bot seems to do, but the test still passes for >>>>>>>>> me. >>>>>>>>> >>>>>>>> >>>>>>>> Running this in the V8 dir seems to reproduce it (thanks to >>>>>>>> Michael): >>>>>>>> >>>>>>>> ./tools/run-tests.py --arch=ia32 --mode=release >>>>>>>> --extra-flags="--noenable-**sse2" >>>>>>>> mjsunit/harmony/object-observe >>>>>>>> >>>>>>>> However, it is flaky. You probably have to run it a few times >>>>>>>> before the failure >>>>>>>> occurs. >>>>>>>> >>>>>>>> Unfortunately, I have no idea off-hand concerning the cause. >>>>>>>> >>>>>>>> >>>>>>>> https://codereview.chromium.**org/23491002/<https://codereview.chromium.org/23491002/> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" 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/groups/opt_out.
