New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 666046 link

Starred by 23 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Tab crashes every time for unknown reason (recent versions of Chrome and Chrome only)

Reported by vitaly.k...@sencha.com, Nov 16 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36

Steps to reproduce the problem:
1. Go to this example: http://examples.sencha.com/extjs/6.2.0/examples/kitchensink/#pie-3d
2. Toggle a slice (e.g. "Android") on an off a few times until the crash happens. Usually takes about 2-7 times.

What is the expected behavior?
No crash.

What went wrong?
We don't know. We have been getting reports from many many customers.

What we do know is:

* This is not related to a build for a specific OS - happens on Mac, Windows and Ubuntu Linux.

* Older versions of Chrome never crash on this page.

* No other browser crashes on this page, just recent versions of Chrome (and Chromium based browsers like Opera).

* This only happens in 64-bit builds.

* Memory profiling in Safari didn't show any memory leaks (around 40KB increase after a minute of chart interaction).

From our QA:

"It seems to affect 64-bit versions of Chromium-blink based browsers since it also fails in latest Opera 42. It works fine in all tested 32 bit browser versions.
64 bit
Chrome 48.0.2564.109 - OK
Chrome64_49.0.2623.75 - OK
Chrome64_50.0.2661.75 - FAIL
Chrome64_51.0.2704.106 - FAIL 
Chrome64_ 53.0.2785.143 - FAIL
Chrome64_54.0.2840.59 - FAIL
Opera 42 - FAIL
32 bit 
Chrome 53.0.2785.143 m - OK
Chrome 54.0.2840.59 m - OK
Opera 40 - OK
And failing on all tested platforms - Win10, Ubuntu Linux and OSX"

Crashed report ID: e0ffdbe2-d7c7-41a9-9d4e-842ea5117826

How much crashed? Just one tab

Is it a problem with a plugin? N/A 

Did this work before? Yes Appears to be 49.0.2623.75

Chrome version: 54.0.2840.98  Channel: stable
OS Version: OS X 10.12.1
Flash Version: Shockwave Flash 23.0 r0

This is a very disruptive issue we
 
Same issue

Comment 2 by rsesek@chromium.org, Nov 16 2016

Components: Blink>JavaScript
Status: Untriaged (was: Unconfirmed)
Confirmed on Mac 56.0.2920.0.

Thread 0 CRASHED [EXC_BAD_ACCESS / EXC_I386_GPFLT @ 0x000000010d979338 ] MAGIC SIGNATURE THREAD
Stack Quality78%Show frame trust levels
0x000000010d979338	(Google Chrome Framework -spaces.h:508 )	v8::internal::Heap::Scavenge()
0x000000010d97736f	(Google Chrome Framework -heap.cc:1328 )	v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags)
0x000000010d97693b	(Google Chrome Framework -heap.cc:998 )	v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags)
0x000000010d9c51cb	(Google Chrome Framework -heap-inl.h:685 )	v8::internal::ScavengeJob::IdleTask::RunInternal(double)
0x00000001113d8ec7	(Google Chrome Framework -web_scheduler_impl.cc:46 )	blink::scheduler::WebSchedulerImpl::runIdleTask(std::__1::unique_ptr<blink::WebThread::IdleTask, std::__1::default_delete<blink::WebThread::IdleTask> >, base::TimeTicks)
0x00000001113d9bbe	(Google Chrome Framework -bind_internal.h:164 )	base::internal::Invoker<base::internal::BindState<void (*)(std::__1::unique_ptr<blink::WebThread::IdleTask, std::__1::default_delete<blink::WebThread::IdleTask> >, base::TimeTicks), base::internal::PassedWrapper<std::__1::unique_ptr<blink::WebThread::IdleTask, std::__1::default_delete<blink::WebThread::IdleTask> > > >, void (base::TimeTicks)>::Run(base::internal::BindStateBase*, base::TimeTicks&&)
0x00000001113d895f	(Google Chrome Framework -callback.h:64 )	blink::scheduler::SingleThreadIdleTaskRunner::RunTask(base::Callback<void (base::TimeTicks), (base::internal::CopyMode)1, (base::internal::RepeatMode)1>)
0x00000001113d8bde	(Google Chrome Framework -bind_internal.h:214 )	base::internal::Invoker<base::internal::BindState<void (blink::scheduler::SingleThreadIdleTaskRunner::*)(base::Callback<void (base::TimeTicks), (base::internal::CopyMode)1, (base::internal::RepeatMode)1>), base::WeakPtr<blink::scheduler::SingleThreadIdleTaskRunner>, base::Callback<void (base::TimeTicks), (base::internal::CopyMode)1, (base::internal::RepeatMode)1> >, void ()>::Run(base::internal::BindStateBase*)
0x000000010eafb300	(Google Chrome Framework -callback.h:47 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x00000001113d09d2	(Google Chrome Framework -task_queue_manager.cc:358 )	blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*)
0x00000001113cf609	(Google Chrome Framework -task_queue_manager.cc:250 )	blink::scheduler::TaskQueueManager::DoWork(base::TimeTicks, bool)
0x000000010eafb300	(Google Chrome Framework -callback.h:47 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x000000010eb1edc5	(Google Chrome Framework -message_loop.cc:413 )	base::MessageLoop::RunTask(base::PendingTask*)
0x000000010eb1f09b	(Google Chrome Framework -message_loop.cc:422 )	base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
0x000000010eb1f3e2	(Google Chrome Framework -message_loop.cc:515 )	base::MessageLoop::DoWork()
0x000000010eb21a0c	(Google Chrome Framework -message_pump_mac.mm:302 )	base::MessagePumpCFRunLoopBase::RunWork()
0x000000010eb14049	(Google Chrome Framework + 0x0187e049 )	base::mac::CallWithEHFrame(void () block_pointer)
0x000000010eb21483	(Google Chrome Framework -message_pump_mac.mm:278 )	base::MessagePumpCFRunLoopBase::RunWorkSource(void*)
0x00007fff882da880	(CoreFoundation + 0x000aa880 )	__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
0x00007fff882b9fbb	(CoreFoundation + 0x00089fbb )	__CFRunLoopDoSources0
0x00007fff882b94de	(CoreFoundation + 0x000894de )	__CFRunLoopRun
0x00007fff882b8ed7	(CoreFoundation + 0x00088ed7 )	CFRunLoopRunSpecific
0x00007fff886cbed8	(Foundation + 0x00024ed8 )	-[NSRunLoop(NSRunLoop) runMode:beforeDate:]
0x000000010eb2208d	(Google Chrome Framework -message_pump_mac.mm:580 )	base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*)
0x000000010eb218cb	(Google Chrome Framework -message_pump_mac.mm:210 )	base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*)
0x000000010eb3cbc2	(Google Chrome Framework -run_loop.cc:35 )	base::RunLoop::Run()
0x00000001125d3f5e	(Google Chrome Framework -renderer_main.cc:198 )	content::RendererMain(content::MainFunctionParams const&)
0x000000010e6a9a3c	(Google Chrome Framework -content_main_runner.cc:774 )	content::ContentMainRunnerImpl::Run()
0x000000010e6a8cd5	(Google Chrome Framework -content_main.cc:20 )	content::ContentMain(content::ContentMainParams const&)
0x000000010d298fab	(Google Chrome Framework -chrome_main.cc:97 )	ChromeMain
0x000000010d05fda9	(Google Chrome Helper -chrome_exe_main_mac.c:85 )	main
0x00007fff8c9715ac	(libdyld.dylib + 0x000035ac )	

Comment 3 by rsesek@chromium.org, Nov 16 2016

That's crash/365c5caf00000000 above.

Comment 4 by danno@chromium.org, Nov 17 2016

Cc: mlippautz@chromium.org u...@chromium.org
Owner: hpayer@chromium.org
Status: Assigned (was: Untriaged)
Triaging. Please close if the problem isn't actionable

Comment 5 by hpayer@chromium.org, Nov 18 2016

Cc: hpayer@chromium.org
Owner: jgruber@chromium.org
Assigning to the current memory sheriff. Jakob, please have a look.
Labels: -OS-Mac OS-All
Can reproduce on Linux on both versions I tried:

Version 56.0.2914.3 dev (64-bit)
Version 54.0.2840.90 (64-bit)

Building chrome now for more details.
Stack trace from content_shell. The object passed in frame 3 looks suspicious:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc00a6700 (LWP 14614)]
0x00007fffed0867ec in v8::base::Flags<v8::internal::MemoryChunk::Flag, unsigned long>::operator& (this=0x4016474f0a100008, flags=...)
    at ../../v8/src/base/flags.h:55
55	  Flags operator&(const Flags& flags) const { return Flags(*this) &= flags; }
(gdb) bt
#0  0x00007fffed0867ec in v8::base::Flags<v8::internal::MemoryChunk::Flag, unsigned long>::operator& (this=0x4016474f0a100008, flags=...)
    at ../../v8/src/base/flags.h:55
#1  0x00007fffed0867b3 in v8::base::Flags<v8::internal::MemoryChunk::Flag, unsigned long>::operator& (this=0x4016474f0a100008, 
    flag=v8::internal::MemoryChunk::IN_FROM_SPACE) at ../../v8/src/base/flags.h:63
#2  0x00007fffed08675f in v8::internal::MemoryChunk::IsFlagSet (this=0x4016474f0a100000, flag=v8::internal::MemoryChunk::IN_FROM_SPACE)
    at ../../v8/src/heap/spaces.h:508
#3  0x00007fffed7f4a33 in v8::internal::Heap::InFromSpace (this=0x137d9b0e9040, object=0x4016474f0a174915)
    at ../../v8/src/heap/heap-inl.h:474
#4  0x00007fffed7fb4a0 in v8::internal::Scavenger::CheckAndScavengeObject (heap=0x137d9b0e9040, 
    slot_address=0x28e3ff3a160 "\025I\027\nOG\026@\t#p7*\004") at ../../v8/src/heap/scavenger-inl.h:44
#5  0x00007fffed7e4bb0 in v8::internal::Heap::Scavenge()::$_0::operator()(unsigned char*) const (this=0x7fffc00a0418, 
    addr=0x28e3ff3a160 "\025I\027\nOG\026@\t#p7*\004") at ../../v8/src/heap/heap.cc:1655
#6  0x00007fffed7e4a74 in v8::internal::SlotSet::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::Heap::Scavenge()::$_0, v8::internal::SlotSet::EmptyBucketMode) (this=0x137da09ebc28, callback=..., mode=v8::internal::SlotSet::PREFREE_EMPTY_BUCKETS)
    at ../../v8/src/heap/slot-set.h:183
#7  0x00007fffed7e4938 in v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::MemoryChunk*, v8::internal::Heap::Scavenge()::$_0) (chunk=0x28e3ff00000, callback=...) at ../../v8/src/heap/remembered-set.h:121
#8  0x00007fffed7e48a8 in void v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::Heap*, v8::internal::Heap::Scavenge()::$_0)::{lambda(v8::internal::MemoryChunk*)#1}::operator()(v8::internal::MemoryChunk*) const (this=0x7fffc00a0508, chunk=0x28e3ff00000) at ../../v8/src/heap/remembered-set.h:92
#9  0x00007fffed7e4874 in v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::IterateMemoryChunks<void v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::Heap*, v8::internal::Heap::Scavenge()::$_0)::{lambda(v8::internal::MemoryChunk*)#1}>(v8::internal::Heap*, void v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::Heap*, v8::internal::Heap::Scavenge()::$_0)::{lambda(v8::internal::MemoryChunk*)#1}) (heap=0x137d9b0e9040, callback=...) at ../../v8/src/heap/remembered-set.h:105
#10 0x00007fffed7cfb35 in v8::internal::RememberedSet<(v8::internal::PointerDirection)1>::Iterate<v8::internal::Heap::Scavenge()::$_0>(v8::internal::Heap*, v8::internal::Heap::Scavenge()::$_0) (heap=0x137d9b0e9040, callback=...) at ../../v8/src/heap/remembered-set.h:91
#11 0x00007fffed7ce5f4 in v8::internal::Heap::Scavenge (this=0x137d9b0e9040) at ../../v8/src/heap/heap.cc:1654
#12 0x00007fffed7ccb22 in v8::internal::Heap::PerformGarbageCollection (this=0x137d9b0e9040, collector=v8::internal::SCAVENGER, 
    gc_callback_flags=v8::kNoGCCallbackFlags) at ../../v8/src/heap/heap.cc:1324
#13 0x00007fffed7cbf9b in v8::internal::Heap::CollectGarbage (this=0x137d9b0e9040, collector=v8::internal::SCAVENGER, 
    gc_reason=v8::internal::GarbageCollectionReason::kAllocationFailure, collector_reason=0x0, gc_callback_flags=v8::kNoGCCallbackFlags)
    at ../../v8/src/heap/heap.cc:994
#14 0x00007fffed0ded7e in v8::internal::Heap::CollectGarbage (this=0x137d9b0e9040, space=v8::internal::NEW_SPACE, 
    gc_reason=v8::internal::GarbageCollectionReason::kAllocationFailure, callbackFlags=v8::kNoGCCallbackFlags)
    at ../../v8/src/heap/heap-inl.h:685
#15 0x00007fffed76ed55 in v8::internal::Factory::NewFixedArray (this=0x137d9b0e9020, size=17, pretenure=v8::internal::NOT_TENURED)
    at ../../v8/src/factory.cc:134
#16 0x00007fffed9dfec0 in v8::internal::HashTable<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::New (isolate=0x137d9b0e9020, at_least_space_for=2, capacity_option=v8::internal::USE_DEFAULT_MINIMUM_CAPACITY, 
    pretenure=v8::internal::NOT_TENURED) at ../../v8/src/objects.cc:16883
#17 0x00007fffed9f2a0d in v8::internal::HashTable<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::EnsureCapacity (table=..., n=1, key=..., pretenure=v8::internal::NOT_TENURED) at ../../v8/src/objects.cc:17059
#18 0x00007fffed9f1a50 in v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::EnsureCapacity (dictionary=..., n=1, key=...) at ../../v8/src/objects.cc:18062
#19 0x00007fffed9e3d92 in v8::internal::Dictionary<v8::internal::NameDictionary, v8::internal::NameDictionaryShape, v8::internal::Handle<v8::internal::Name> >::Add (dictionary=..., key=..., value=..., details=..., entry_out=0x7fffc00a104c) at ../../v8/src/objects.cc:18111
#20 0x00007fffed94b82a in v8::internal::LookupIterator::ApplyTransitionToDataProperty (this=0x7fffc00a13e8, receiver=...)
    at ../../v8/src/lookup.cc:401
#21 0x00007fffed9931a8 in v8::internal::Object::AddDataProperty (it=0x7fffc00a13e8, value=..., attributes=v8::internal::NONE, 
    should_throw=v8::internal::Object::DONT_THROW, store_mode=v8::internal::Object::MAY_BE_STORE_FROM_KEYED)
    at ../../v8/src/objects.cc:5000
#22 0x00007fffed991633 in v8::internal::Object::SetProperty (it=0x7fffc00a13e8, value=..., 
    language_mode=v8::internal::LanguageMode::SLOPPY, store_mode=v8::internal::Object::MAY_BE_STORE_FROM_KEYED)
    at ../../v8/src/objects.cc:4767
#23 0x00007fffedb8ca1d in v8::internal::Runtime::SetObjectProperty (isolate=0x137d9b0e9020, object=..., key=..., value=..., 
    language_mode=v8::internal::LanguageMode::SLOPPY) at ../../v8/src/runtime/runtime-object.cc:292
#24 0x00007fffedb8fccd in v8::internal::__RT_impl_Runtime_SetProperty (args=..., isolate=0x137d9b0e9020)
    at ../../v8/src/runtime/runtime-object.cc:436
#25 0x00007fffedb8f830 in v8::internal::Runtime_SetProperty (args_length=4, args_object=0x7fffc00a15f8, isolate=0x137d9b0e9020)
    at ../../v8/src/runtime/runtime-object.cc:427
#26 0x00001ab91cc843a7 in ?? ()
#27 0x00007fffc00a1630 in ?? ()
#28 0x00001ab91cc842e1 in ?? ()
#29 0x00007fffc00a15b0 in ?? ()
#30 0x0000000300000000 in ?? ()
#31 0x00007fffc00a1640 in ?? ()
#32 0x00001ab91d33b012 in ?? ()
#33 0x0000000000000000 in ?? ()
Also reproduces on content_shell with --predictable. The value of 'this' for e.g. frame 2 in the above trace is usually 0x4016474f0a100008.
What appears to be happening is that GC interprets unboxed double fields as pointers.

An example object:

(gdb) job 0x1db73c40d0e9
0x1db73c40d0e9: [JS_OBJECT_TYPE]
 - map = 0x1506cf435e71 [FastProperties]
 - prototype = 0x36f9f025d591
 - elements = 0x391473a82241 <FixedArray[0]> [FAST_HOLEY_ELEMENTS]
 - properties = {
   #prototype: 0x36f9f025d591 <an Object with map 0x1506cf43f871> (data field at offset 0)
   #highlighted: 0x391473a82421 <false> (data field at offset 1)
   #highlightOriginal: 0x1db73c473749 <an Object with map 0x316fc5dc6671> (data field at offset 2)
   #startAngle: <unboxed double> 4.29142 (data field at offset 3)
   #endAngle: !!!INVALID POINTER!!! (data field at offset 4)

And its map:

(gdb) job 0x00001506cf435e71
0x1506cf435e71: [Map]
 - type: JS_OBJECT_TYPE
 - instance size: 56
 - inobject properties: 4
 - elements kind: FAST_HOLEY_ELEMENTS
 - unused property fields: 2
 - enum length: invalid
 - stable_map
 - prototype_map
 - prototype info: 0x3f462c7e5931 <PrototypeInfo>
 - instance descriptors (own) #5: !!!INVALID POINTER!!!
 - layout descriptor: 8
 - prototype: 0x36f9f025d591 <an Object with map 0x1506cf43f871>
 - constructor: 0x2b9e02b963e1 <JS Function Object (SharedFunctionInfo 0x391473a8b8c1)>
 - code cache: 0x391473a82241 <FixedArray[0]>
 - dependent code: 0x391473a82241 <FixedArray[0]>
 - construction counter: 0

Relevant memory area:

(gdb) x/16gx 0x1db73c40d118 - 64
0x1db73c40d0d8:	0x0000012000000000	0x0000000100000000
0x1db73c40d0e8:	0x00001506cf435e71	0x00003113c3114169
0x1db73c40d0f8:	0x0000391473a82241	0x000036f9f025d591
0x1db73c40d108:	0x0000391473a82421	0x00001db73c473749
0x1db73c40d118:	0x40112a68d7818221	0x00001f3121e82309
0x1db73c40d128:	0x0000000b00000000	0x0000000300000000
0x1db73c40d138:	0x0000000000000000	0x0000391473a83659
0x1db73c40d148:	0x0000012000000000	0x0000000100000000

The crash occurs on object.startAngle.
Cc: ishell@chromium.org
+ishell, any ideas?
Cc: jgruber@chromium.org
Owner: ishell@chromium.org
Interesting...
Status: Started (was: Assigned)
The fix is on the way...
Project Member

Comment 13 by bugdroid1@chromium.org, Nov 28 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/a814b8aeaf2b56635054c96435972dce90576f62

commit a814b8aeaf2b56635054c96435972dce90576f62
Author: ishell <ishell@chromium.org>
Date: Mon Nov 28 20:11:00 2016

[heap] Clear recorded slots for inobject properties when migrating fast object to slow mode.

BUG= chromium:666046 

Review-Url: https://codereview.chromium.org/2539493002
Cr-Commit-Position: refs/heads/master@{#41327}

[modify] https://crrev.com/a814b8aeaf2b56635054c96435972dce90576f62/src/objects.cc
[add] https://crrev.com/a814b8aeaf2b56635054c96435972dce90576f62/test/mjsunit/regress/regress-666046.js

Cc: jkummerow@chromium.org hablich@chromium.org
Labels: Merge-Request-54 Merge-Request-55
Status: Fixed (was: Started)
Labels: -Merge-Request-54 -Merge-Request-55 Merge-rejected-5.4 Merge-approved-5.6 merge-approved-5.5
Please merge to the appropriate branches after it has Canary coverage (it is not yet rolled into Chromium).

5.4 is already deprecated btw.
Labels: -Pri-2 Pri-1
Very nice!
Project Member

Comment 19 by sheriffbot@chromium.org, Dec 2 2016

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 20 by bugdroid1@chromium.org, Dec 2 2016

Labels: merge-merged-5.6
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/a2f8f48b4f13f1c36a9009d2920a11fb400d65a1

commit a2f8f48b4f13f1c36a9009d2920a11fb400d65a1
Author: ishell@chromium.org <ishell@chromium.org>
Date: Fri Dec 02 14:52:29 2016

Merged: [heap] Clear recorded slots for inobject properties when migrating fast object to slow mode.

Revision: a814b8aeaf2b56635054c96435972dce90576f62

BUG= chromium:666046 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/2545553005 .

Cr-Commit-Position: refs/branch-heads/5.6@{#26}
Cr-Branched-From: bdd3886218dfe76e8560eb8a18401942452ae859-refs/heads/5.6.326@{#1}
Cr-Branched-From: 879f6599eee6e1dfcbe9a24bf688b261c03e9558-refs/heads/master@{#41014}

[modify] https://crrev.com/a2f8f48b4f13f1c36a9009d2920a11fb400d65a1/src/objects.cc
[add] https://crrev.com/a2f8f48b4f13f1c36a9009d2920a11fb400d65a1/test/mjsunit/regress/regress-666046.js

Project Member

Comment 21 by bugdroid1@chromium.org, Dec 2 2016

Labels: merge-merged-5.5
The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/8e38ce835dfecd68a39d468e7a6d843d22caf812

commit 8e38ce835dfecd68a39d468e7a6d843d22caf812
Author: ishell@chromium.org <ishell@chromium.org>
Date: Fri Dec 02 15:09:19 2016

Merged: [heap] Clear recorded slots for inobject properties when migrating fast object to slow mode.

Revision: a814b8aeaf2b56635054c96435972dce90576f62

BUG= chromium:666046 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=ulan@chromium.org

Review URL: https://codereview.chromium.org/2549803002 .

Cr-Commit-Position: refs/branch-heads/5.5@{#60}
Cr-Branched-From: 3cbd5838bd8376103daa45d69dade929ee4e0092-refs/heads/5.5.372@{#1}
Cr-Branched-From: b3c8b0ce2c9af0528837d8309625118d4096553b-refs/heads/master@{#40015}

[modify] https://crrev.com/8e38ce835dfecd68a39d468e7a6d843d22caf812/src/objects.cc
[add] https://crrev.com/8e38ce835dfecd68a39d468e7a6d843d22caf812/test/mjsunit/regress/regress-666046.js

Project Member

Comment 22 by bugdroid1@chromium.org, Dec 2 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/1094cdc1ead43c4600d3cc5eaaaa011f8b85ccc1

commit 1094cdc1ead43c4600d3cc5eaaaa011f8b85ccc1
Author: ishell@chromium.org <ishell@chromium.org>
Date: Fri Dec 02 19:21:37 2016

Merged: [heap] Clear recorded slots for inobject properties when migrating fast object to slow mode.

Revision: a814b8aeaf2b56635054c96435972dce90576f62

(this CL removes extra trailing space left after a manual conflict resolution in previous backmerge).

BUG= chromium:666046 
LOG=N
NOTRY=true
NOPRESUBMIT=true
NOTREECHECKS=true
R=hablich@chromium.org

Review URL: https://codereview.chromium.org/2545143002 .

Cr-Commit-Position: refs/branch-heads/5.5@{#62}
Cr-Branched-From: 3cbd5838bd8376103daa45d69dade929ee4e0092-refs/heads/5.5.372@{#1}
Cr-Branched-From: b3c8b0ce2c9af0528837d8309625118d4096553b-refs/heads/master@{#40015}

[modify] https://crrev.com/1094cdc1ead43c4600d3cc5eaaaa011f8b85ccc1/src/objects.cc

Labels: -merge-approved-5.5 -Merge-approved-5.6
Labels: NodeJS-Backport-Approved
Also needed for Node.js v7.x (V8 5.4). We'll handle the backport on the Node.js side.
Also needed for Node.js v6.x (V8 5.1).
Labels: -NodeJS-Backport-Approved NodeJS-Backport-Done
Fixed in node on https://github.com/nodejs/node/pull/10733.

Sign in to add a comment