Closed Bug 1207165 Opened 9 years ago Closed 9 years ago

crash @ xul!AssertNotOnGrayList+0x00000138

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox41 --- ?
firefox42 --- ?
firefox43 --- ?
firefox44 + unaffected

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: csectype-wildptr, sec-critical)

Attachments

(1 file)

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
I'd guess that this is a dupe of that image-related memory corruption that Seth is working on.
Component: JavaScript Engine → JavaScript: GC
If so, bug 1206836 is fixed now, so we shouldn't be hitting this anymore. Should this be resolved?
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*) ]
Well, that's unfortunate. Thanks for retesting, Bob. I guess there's some other issue that's trashing memory.
No longer depends on: 1206836
Group: core-security → javascript-core-security
Bob, could you maybe bisect this to figure out what change set caused it? Assuming it is a regression.
Flags: needinfo?(bob)
(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.
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.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bob)
Resolution: --- → WORKSFORME
Group: javascript-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: