With combined signatures, it's #5 top crasher in today's build.
It first appeared in 16.0a1/20120606. The regression range is:
Signature JSObject::getGeneric(JSContext*, JS::Handle<int>, JS::Value*) More Reports Search
Date Processed 2012-06-06 18:45:30
Last Crash more than 3 months before submission
Install Age 19.1 minutes since version was first installed.
Install Time 2012-06-06 18:25:56
Build ID 20120606030528
Release Channel nightly
OS Windows NT
OS Version 6.1.7601 Service Pack 1
Build Architecture x86
Build Architecture Info GenuineIntel family 6 model 37 stepping 5
Crash Reason EXCEPTION_ACCESS_VIOLATION_READ
Crash Address 0x69727453
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0046, AdapterSubsysID: 043f1028, AdapterDriverVersion: 188.8.131.5222
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+
Adapter Device ID
Total Virtual Memory 2147352576
Available Virtual Memory 1530040320
System Memory Use Percentage 40
Available Page File 4256292864
Available Physical Memory 1836113920
Frame Module Signature Source
1 mozjs.dll JSObject::getGeneric js/src/jsobjinlines.h:177
2 mozjs.dll JSObject::getProperty js/src/jsobjinlines.h:183
3 mozjs.dll js::Interpret js/src/jsinterp.cpp:1489
4 mozjs.dll js::types::TypeSet::addType js/src/jsinferinlines.h:1116
5 mozjs.dll js::types::TypeScript::SetThis js/src/jsinferinlines.h:690
6 mozjs.dll js::Execute js/src/jsinterp.cpp:493
More reports at:
This shows as highly exploitable on Windows in crash automation. I'll see about reproducing.
JSObject::getGeneric(JSContext*, JS::Handle<jsid>, JS::Value*) JSObject::getProperty(JSContext*, js::PropertyName*, JS::Value*) js::GetObjectElementOperation js::GetElementOperation js::Interpret(JSContext*, js::StackFrame*, js::InterpMode)
The url is:
I haven't been able to reproduce locally however. Note that Mac has a different stack/assertion:
Assertion failure: (ptrBits & 0x7) == 0
JSVAL_TO_OBJECT_IMPL JS::Value::toObject js::CompartmentChecker::check
Windows XP once gave the following stack:
js::EncapsulatedPtr<js::types::TypeObject, unsigned int>::operator->() js::ObjectImpl::hasSingletonType() js::types::Type::ObjectType(JSObject*) js::types::GetValueType(JSContext*, JS::Value const&) js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&)
Note the crash reason for the exploitable windows crashes was EXCEPTION_ACCESS_VIOLATION_EXEC
I was able to repro the crash with one of the URLs (http://www.factorydirect.ca/), but I get a slightly different stack:
I wasn't able to reproduce this crash, it is to randomly, I've try to keep my attention on Error Console without luck, any way this crash happen for me on one very popular Polish IT Forums, only during navigation between sub forums and Forum -> Portal page, never on Portal, forum is based on phpBB with their own Mods.
Since I'm completely new on Bugzilla I will not post link now, if someone need it, please let me know in comment.
*** Bug 763073 has been marked as a duplicate of this bug. ***
This is odd, almost whole day without single crash, no I got 3 in 15 minutes, last two in almost same time:
Some steps to reproduce:
1. Go to this Forum: http://forum.dobreprogramy.pl/
2. navigate a bit on site, sub forums etc.
3. On top of Page You can find header with "Forum Dobreprogramy"
4. "Dobreprogramy" lead to Portal page, use it, 99% times crash happen form me on this link.
This is very not regular, You can browse there few hours without single crash and suddenly when You use this link browser crash.
Hope this can help a bit.
Given the regression range, could this be bug 659577?
Yes, there was definitely a big spike in this crash caused by bug 659577. However, the fix landed a few days later and the crashes practically all went away. If I look at crash-stats now, this is #42 and dropping; there is only one crash after 20120608, so I think we can resolve fixed here?
(In reply to Luke Wagner [:luke] from comment #8)
> If I look at crash-stats now, this is #42 and dropping; there is
> only one crash after 20120608, so I think we can resolve fixed here?
There are still crashes in 15.0a2 and 16.0a1 at a very low volume.
Can we make the bug public?
OK news is this appears fixed on 16 via bug 659577! Thanks Naveed, Luke, and Brian for checking :)