Closed
Bug 602162
Opened 14 years ago
Closed 14 years ago
Consistent crash [@ mozjs!JS::PerfMeasurement::canMeasureSomething ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: asmodai, Unassigned)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
60.82 KB,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 ( .NET CLR 3.5.30729; .NET4.0E)
Build Identifier: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20101005 Firefox/4.0b7pre
Using the latest nightly available on 2010-10-06 I went to check the latest score on html5test.com as I always do with a new nightly when I update.
Doing so caused Windows to issue a Debug/Close Program dialog box. The Firefox crash reporter did NOT pop up.
After talking a bit with Henri Sivonen he pointed me to debugging information using Visual Studio. I then proceded to use Windbg to debug the issue and found the following:
FAULTING_IP:
mozjs!JS::PerfMeasurement::canMeasureSomething+de
000007fe`ee30b60e ffe0 jmp rax
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
.exr 0xffffffffffffffff
ExceptionAddress: 000007feee30b60e (mozjs!JS::PerfMeasurement::canMeasureSomething+0x00000000000000de)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff
Reproducible: Always
Steps to Reproduce:
1. Have nightly installed on Windows 7
2. Load http://www.html5test.com/ or use the internal Addon page for finding new addons
3. Watch the Debug/Close Program dialog box pop up.
Actual Results:
Firefox crashes.
Expected Results:
Load the page with no problems.
Clean profile, defaults used, no addons installed.
Reporter | ||
Comment 1•14 years ago
|
||
Updated•14 years ago
|
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: crash
Product: Firefox → Core
QA Contact: general → general
Summary: Consistent crash in mozjs!JS::PerfMeasurement::canMeasureSomething → Consistent crash [@ mozjs!JS::PerfMeasurement::canMeasureSomething ]
Version: unspecified → Trunk
Attachment #481168 -
Attachment mime type: application/octet-stream → text/plain
Reporter | ||
Comment 3•14 years ago
|
||
If the directions for using symbols per https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg are not good enough to get the symbols (as my debug attachments show in getting 404s) then I'll gladly hear how to improve on that.
Reporter | ||
Comment 4•14 years ago
|
||
Setting javascript.options.methodjit.content to false solves the crash and switches the tab from the installed addons to the find new addons.
Updated•14 years ago
|
blocking2.0: --- → ?
Comment 5•14 years ago
|
||
Hello,
I see this problem too.
I am using FF 4.0 beta 64 bit in the last 2-3 months and it was pretty stable.
I get an update almost every day.
a few days ago ( around october 1st) it started to crash constantly. even on a new installations of windows. ( this probably means there is no addons installed)
mozilla symbol server does not provide symbols for the nightly 64 bit and there is no debug build.
The crash reporter does not catch this crash.
Sorry, we don't seem to be generating/pushing 64bit symbols to the symbol server. which means you have to wait (there's a bug, you can find it).
Hardware: x86 → x86_64
Reporter | ||
Comment 7•14 years ago
|
||
bug 602162 to be precise
Reporter | ||
Comment 8•14 years ago
|
||
Nevermind that, no fully awake yet. >_<
Updated•14 years ago
|
Assignee: general → sphink
Updated•14 years ago
|
blocking2.0: ? → betaN+
Updated•14 years ago
|
blocking2.0: betaN+ → final+
Reporter | ||
Comment 9•14 years ago
|
||
Using the 64 bit build from the 20th and reenabling the javascript.options.methodjit.content setting I cannot reproduce this problem.
For me, just visiting html5test.com with this setting enabled caused the crashes. It does not crash on that anymore at least.
Albarzilai: can you double check what I found to see if your stability is also improved?
Updated•14 years ago
|
Assignee: sphink → general
Reporter | ||
Comment 10•14 years ago
|
||
I'll close this one as worksforme (as discussed with Matthias), since the build from the 20th solved this issue. If it crops up, I'll either reopen or open a new one.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Comment 11•14 years ago
|
||
Hi,
After using either the build from the 20th or javascript fix on the build from the 13th, snd I have not seen a crash since.
anyone knows why there are no new builds in
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk ?
and the updates do not work either.
Updated•14 years ago
|
Crash Signature: [@ mozjs!JS::PerfMeasurement::canMeasureSomething ]
You need to log in
before you can comment on or make changes to this bug.
Description
•