Closed Bug 595834 Opened 15 years ago Closed 15 years ago

Crash [@ js::Interpret(JSContext*, JSStackFrame*, unsigned int, unsigned int) ][@ js::Interpret ]

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: scoobidiver, Assigned: dmandelin)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

Build : Mozilla/5.0 (Windows NT 6.1; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre This is a new crash signature that was introduced by this build. It is #4 top crasher for this build. It happens mainly at start-up. Start-up crash signature : Signature js::Interpret(JSContext*, JSStackFrame*, unsigned int, unsigned int) UUID 1e3cd720-1ce3-4e58-872b-0e4bf2100913 Time 2010-09-13 03:36:55.972552 Uptime 3 Last Crash 46 seconds before submission Install Age 36333 seconds (10.1 hours) since version was first installed. Product Firefox Version 4.0b6pre Build ID 20100912041924 Branch 2.0 OS Windows NT OS Version 5.1.2600 Service Pack 3 CPU x86 CPU Info AuthenticAMD family 6 model 10 stepping 0 Crash Reason EXCEPTION_ILLEGAL_INSTRUCTION Crash Address 0x7120650 App Notes AdapterVendorID: 1002, AdapterDeviceID: 9505 Crashing Thread Frame Module Signature [Expand] Source 0 @0x7120650 1 xul.dll js::Interpret js/src/jsinterp.cpp:4595 2 xul.dll js::Invoke js/src/jsinterp.cpp:614 3 xul.dll js::mjit::stubs::SlowCall js/src/methodjit/InvokeHelpers.cpp:260 4 xul.dll CallCompiler::update js/src/methodjit/MonoIC.cpp:613 5 xul.dll js::mjit::ic::Call js/src/methodjit/MonoIC.cpp:689 6 @0x71e39ca 7 xul.dll js::Interpret js/src/jsinterp.cpp:4595 8 xul.dll js::Invoke js/src/jsinterp.cpp:614 9 xul.dll js::mjit::stubs::SlowCall js/src/methodjit/InvokeHelpers.cpp:260 10 xul.dll CallCompiler::update js/src/methodjit/MonoIC.cpp:613 11 xul.dll js::mjit::ic::Call js/src/methodjit/MonoIC.cpp:689 12 @0x71e20fb 13 xul.dll js::Invoke js/src/jsinterp.cpp:614 14 xul.dll js::ExternalInvoke js/src/jsinterp.cpp:644 15 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1692 16 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:571 17 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 18 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 19 xul.dll nsObserverList::NotifyObservers xpcom/ds/nsObserverList.cpp:130 20 xul.dll xul.dll@0xc4bc4b 21 xul.dll nsObserverService::NotifyObservers xpcom/ds/nsObserverService.cpp:182 22 xul.dll nsHttpHandler::NotifyObservers netwerk/protocol/http/nsHttpHandler.cpp:552 23 xul.dll nsHttpChannel::AsyncOpen netwerk/protocol/http/nsHttpChannel.cpp:3503 24 xul.dll imgLoader::LoadImage modules/libpr0n/src/imgLoader.cpp:1660 25 xul.dll nsLoadGroup::AggregatedQueryInterface netwerk/base/src/nsLoadGroup.cpp:210 The regression range is : http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=73ab2c3c5ad9&tochange=cd3c926a7413
blocking2.0: --- → ?
Comments from linked Crashes: "When browsing any site except about:home (since the JM merge) New profile, all addons and plugins disabled." "When browse any site excepted about:home" "Crashed immediately on trying to load first web page." "Firefox crashed when I've tried to unblock javascript." No particular Extensions seem to be involved.
I don't see this with a 09-23-2010 buildid yet.
blocking2.0: ? → beta8+
Scoobidiver, have you seen this with any of the recent builds?
It happens also on Mac OS X and Linux.
Summary: Crash [@ js::Interpret(JSContext*, JSStackFrame*, unsigned int, unsigned int) ] → Crash [@ js::Interpret(JSContext*, JSStackFrame*, unsigned int, unsigned int) ][@ js::Interpret ]
A couple of notes: 1. This is no longer mostly a startup crash. 2. |Interpret| topcrashes need special treatment. |Interpret| is a huge function, so a topcrash there is always multiple bugs getting combined together. Right now, the biggest cluster, as determined by detailed crash signature (esp. line of code at crash) is exemplified by: https://crash-stats.mozilla.com/report/index/b1e63dc3-af01-423a-945b-070a62101101 The second biggest cluster looks like this one: https://crash-stats.mozilla.com/report/index/102970e7-165a-45a7-93ee-020a82101031 How should we track these? My first thought is to create 2 new bugs which block this one. But that interacts in funny ways with blocking status. What blocks here, exactly? Fixing both those bugs? Fixing one? Reducing the frequency of this crash by X amount by any means? Not clear. The simplest answer seems to be to file 2 new bugs blocking this one, make them block beta8 just like this one, then revisit their status as needed.
Depends on: 608874
Depends on: 609063
> The simplest answer seems to be to file 2 new bugs blocking this one, make them > block beta8 just like this one, then revisit their status as needed. yeah, thats a good strategy. this tracking bug no longer needs to block and we can make individual decisions on each of the spin off bugs
Assignee: general → dmandelin
Unblocking per comment 7. Right now, crash volume in Interpret is pretty low. If crash volume upticks, please add a comment here with some info (date it started, anything that clusters about the new crash report) and whether it should block, and I will analyze it and file new dependent bug(s) accordingly.
blocking2.0: beta8+ → -
It is #9 top crasher in Fennec 4.0b3pre for the last week.
tracking-fennec: --- → ?
Keywords: topcrash
OS: Windows XP → All
Hardware: x86 → All
I don't see this in crash-stats anymmore.
Status: NEW → RESOLVED
tracking-fennec: ? → ---
Closed: 15 years ago
Resolution: --- → FIXED
No longer depends on: 609063
Depends on: 609063
Crash Signature: [@ js::Interpret(JSContext*, JSStackFrame*, unsigned int, unsigned int) ] [@ js::Interpret ]
You need to log in before you can comment on or make changes to this bug.