1207165 - crash @ xul!AssertNotOnGrayList+0x00000138

Status: RESOLVED WORKSFORME

(Core :: JavaScript: GC, defect)

Description

[Carsten Book [:Tomcat]]

Attachment: windgb information from this url

found via bughunter on https://twitter.com/hashtag/ViernesDePiropos?src=tren&lang=es

and reproduced after multiple tries to load this site.

Bughunter is reporting a lot of different stacks for this site like signatures like : JS::Heap<JSObject*>::~Heap<JSObject*> `vector destructor iterator' mozilla::dom::ProtoAndIfaceCache::~ProtoAndIfaceCache mozilla::dom::DestroyProtoAndIfaceCache mozilla::dom::DedicatedWorkerGlobalScopeBinding_workers::_finalize

however i was able to catch a crash (xul!AssertNotOnGrayList+0x00000138) in windgb from this site.

STACK_TEXT:  
002defc8 5e6e383e 10c7ce70 002df154 02913210 xul!AssertNotOnGrayList+0x138
002df04c 5e708aef 0a417c00 02913210 002df154 xul!js::gc::GCRuntime::beginSweepPhase+0x1de
002df078 5e6ff079 002df154 00000030 002df0d4 xul!js::gc::GCRuntime::incrementalCollectSlice+0x29f
002df0c4 5e6ea4fc 00000000 002df154 00000030 xul!js::gc::GCRuntime::gcCycle+0x1c9
002df148 5e6ff33e 00000000 0000000a 00000000 xul!js::gc::GCRuntime::collect+0x17c
002df1a4 5e7179a8 00000030 00000000 00000000 xul!js::gc::GCRuntime::gcSlice+0x8e
002df1b8 5bf393d3 02913000 002df3bc 5d90ea33 xul!js::gc::GCRuntime::notifyDidPaint+0xb8
002df1c4 5d90ea33 006eaee0 002df3e4 002df418 xul!nsXPConnect::NotifyDidPaint+0x14
002df3bc 5d90ee1b 5e715341 5fef6274 a9904c50 xul!nsRefreshDriver::Tick+0x97e
002df3ec 5d90dff2 11d81400 5e715341 00052056 xul!mozilla::RefreshDriverTimer::TickDriver+0x4a
002df430 5d90d358 5e715341 00052056 a9904c50 xul!mozilla::RefreshDriverTimer::Tick+0xc0
002df48c 5d90efd9 a9904c50 00006901 b49c8b48 xul!mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers+0x70
002df4d0 5d90ceff a9904c50 00006901 b49c8b48 xul!mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver+0xb5
002df4f8 5b6f6696 0e0fb730 00646538 00646520 xul!nsRunnableMethodImpl<void (__thiscall mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::*)(mozilla::TimeStamp),1,mozilla::TimeStamp>::Run+0x21
002df5d0 5b72b8c2 016412a0 00000001 002df5ef xul!nsThread::ProcessNextEvent+0x397
002df5e4 5ba3fddf 016412a0 00000001 006640e0 xul!NS_ProcessNextEvent+0x46
002df614 5ba06eb2 006640e0 006640e0 5f80b080 xul!mozilla::ipc::MessagePump::Run+0x125
002df634 5ba06e55 e70c5874 0299a500 006640e0 xul!MessageLoop::RunInternal+0x42
002df668 5ba06b3b 006412a0 00000001 5b9f2e00 xul!MessageLoop::RunHandler+0x50
002df688 5d6e87d0 0298d8c0 00000000 002df6a8 xul!MessageLoop::Run+0x19
002df698 5d749319 0299a500 0298d8c0 002df6bc xul!nsBaseAppShell::Run+0x47
002df6a8 5dfe32a9 0299a500 002df8cc 64125033 xul!nsAppShell::Run+0x16
002df6bc 5e0399ee 0298d8c0 002df8e4 002df8cc xul!nsAppStartup::Run+0x4b
002df898 5e037a7c 00000001 002df9f8 00000000 xul!XREMain::XRE_mainRun+0xbc4
002df8b4 5e03af36 00000000 00066720 002df9f8 xul!XREMain::XRE_main+0x1a3
002df9c8 01353c5c 00000001 00066720 002df9f8 xul!XRE_main+0x39
002dfb68 01353471 00000001 00066720 0061c100 firefox!do_main+0x352
002dfc0c 0135413a 00000001 00066720 00000000 firefox!NS_internal_main+0x11a
002dfc40 013564fd 00000001 000001f0 000669d8 firefox!wmain+0x11e
002dfc88 76b9ee1c bffdf000 002dfcd4 775737eb firefox!__tmainCRTStartup+0xfe
002dfc94 775737eb bffdf000 77de009e 00000000 kernel32!BaseThreadInitThunk+0xe
002dfcd4 775737be 013565c0 bffdf000 00000000 ntdll!__RtlUserThreadStart+0x70
002dfcec 00000000 013565c0 bffdf000 00000000 ntdll!_RtlUserThreadStart+0x1b

Comment 1

[Andrew McCreight [:mccr8]]

I'd guess that this is a dupe of that image-related memory corruption that Seth is working on.

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

I think that would be bug 1206836.

Comment 3

[Seth Fowler [:seth] [:s2h]]

If so, bug 1206836 is fixed now, so we shouldn't be hitting this anymore. Should this be resolved?

Comment 4

[Bob Clary [:bc] (inactive)]

I retested this and although some of the workers are still pending, this still crashes with multiple different stacks on OSX and Windows. One of the Windows crashes is rated high exploitable while another is rated low with buildid 20150923030230 from mozilla-central. I think the exploitability rating plus the variety of stacks makes me think of memory corruption though the opt-asan linux builds haven't shown any errors.

The low rated windows debug crash looked like JSObject::writeBarrierPost nsWrapperCache::ClearWrapper mozilla::dom::HTMLPreElementBinding::_finalize JSObject::finalize js::gc::Arena::finalize<JSObject>

while the high rated windows opt crash looked like `anonymous namespace'::PerformanceEntryComparator::LessThan mozilla::BinarySearchIf<nsTArray_Impl<nsRefPtr<mozilla::dom::PerformanceEntry>, nsTArrayInfallibleAllocator>, detail::ItemComparatorFirstElementGT<mozilla::dom::PerformanceEntry*&, `anonymous namespace'::PerformanceEntryComparator> > nsTArray_Impl<nsRefPtr<mozilla::dom::PerformanceEntry>, nsTArrayInfallibleAllocator>::InsertElementSorted<mozilla::dom::PerformanceEntry*&, `anonymous namespace'::PerformanceEntryComparator, nsTArrayInfallibleAllocator> PerformanceBase::InsertResourceEntry nsPerformance::AddEntry

The OSX crashes appear to be related to jpeg images or jemalloc.

I reproduced locally on osx 10.9.5:

bp-22d56942-e2d8-4996-ada3-c8d172150923 and
[@ PLDHashTable::Iterator::Iterator(PLDHashTable*) ]

bp-f2afbc78-542a-4671-807c-d83a42150923
[@ RemoveSkippableVisitor::Visit(nsPurpleBuffer&, nsPurpleBufferEntry*) ]

Comment 5

[Andrew McCreight [:mccr8]]

Well, that's unfortunate. Thanks for retesting, Bob. I guess there's some other issue that's trashing memory.

Comment 6

[Andrew McCreight [:mccr8]]

Bob, could you maybe bisect this to figure out what change set caused it? Assuming it is a regression.

Comment 7

[Seth Fowler [:seth] [:s2h]]

(In reply to Bob Clary [:bc:] from comment #4)
> The OSX crashes appear to be related to jpeg images or jemalloc.

It's worth noting that the JPEG decoder is one of the few decoders that didn't change in 43. That doesn't mean it doesn't have bugs, but it does mean that at least it's unlikely that the recent set of image decoder changes are the cause.

Comment 8

[Bob Clary [:bc] (inactive)]

I have repeatedly tried on Windows, Linux and OSX to reproduce this again but have failed. I even tried to scroll down the page to make sure I loaded the content which was originally displayed.

So, either the content has changed sufficiently that it no longer reproduces or I was wrong about reproducing it after bug 1206836 was fixed. We can WFM this for now. If I see something similar, I'll file a new bug.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Updating status-firefox44 based on comment 8.