Closed
Bug 623096
Opened 14 years ago
Closed 14 years ago
Firefox 4.0b9pre crash in [@ js::StackSpace::pushSegmentForInvoke(JSContext*, unsigned int, js::InvokeArgsGuard*) ]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcia, Assigned: luke)
References
Details
(Keywords: crash, reproducible, Whiteboard: [sg:critical])
Crash Data
Seen while running http://lcamtuf.coredump.cx/cross_fuzz/cross_fuzz_randomized_20100729_seed.html
My crash report: http://crash-stats.mozilla.com/report/index/bp-b88c1889-963f-4531-9130-f643e2110104
In this particular instance I was running the fuzzer and I got a dialog that the filepicker was unexpectedly closed. After I clicked OK I got this crash.
Frame Module Signature [Expand] Source
0 mozjs.dll js::StackSpace::pushSegmentForInvoke js/src/jscntxt.cpp:265
1 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:842
2 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:5028
3 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1697
4 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:588
5 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
6 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
7 xul.dll nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1114
Reporter | ||
Comment 1•14 years ago
|
||
I was able to reproduce this by following the same steps:
1. Run the fuzzer
2. Wait for the file picker dialog to come up. Press OK.
3. Crash.
Keywords: reproducible
Updated•14 years ago
|
Whiteboard: [sg:critical
Updated•14 years ago
|
Whiteboard: [sg:critical → [sg:critical]
Assignee | ||
Comment 2•14 years ago
|
||
Wow, I am able to get plenty of crashes, just not pushSegmentForInvoke. I'll keep trying.
Comment 3•14 years ago
|
||
running the fuzzer locally and adding a seed value might help in generating consistent results. more about this in https://bugzilla.mozilla.org/show_bug.cgi?id=623189#c1
Blocks: crossfuzz-pvt
Reporter | ||
Comment 4•14 years ago
|
||
A new version was just posted in https://bugzilla.mozilla.org/show_bug.cgi?id=623189#c12, when I get a chance I should try that version the Win XP machine.
When I got this crash I forgot to add I was not running the file locally.
Comment 5•14 years ago
|
||
Marcia: could you get a full minidump of the app?
you'll need to install http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx then
To begin debugging, ensure that Firefox is not already running and open WinDbg from the Start menu. (Start->All Programs->Debugging Tools for Windows->WinDbg) Next, open the "File" menu and choose "Open Executable...". In the file chooser window that appears, open the firefox.exe executable in your Firefox program folder (C:\Program Files\Mozilla Firefox).
Then Debug -> Go. (If it stops again right away, do it again until the browser comes up.)
After it crashes, at the command-line in the debugger, type ".dump /ma c:\bug-623096.dmp" and then once it's complete, you have a (very large) dump file. You can USB key it over to Luke, probably, since he's just at the other end of the floor. :-)
(Above info cribbed from https://developer.mozilla.org/en/how_to_get_a_stacktrace_with_windbg but you don't need the symbol server or stacktrace stuff.)
Updated•14 years ago
|
Assignee: general → lw
blocking2.0: --- → betaN+
Comment 6•14 years ago
|
||
It'd be good to attach a testcase to the bug just in case lcamtuf's online fuzzer changes over time.
Keywords: testcase-wanted
Assignee | ||
Comment 7•14 years ago
|
||
Does this crash reproduce if the mjit is turned off?
Comment 8•14 years ago
|
||
Better instructions for just getting the minidump:
https://developer.mozilla.org/User:Shaver/Capturing_a_minidump
Reporter | ||
Comment 9•14 years ago
|
||
Since the original crash, I have not been able to reproduce this on the same machine with the original fuzzer. I have also tried running the new fuzzer in Comment 4 but I have yet to crash with that one at all. Will continue trying as well as installing windbg on that XP machine.
Reporter | ||
Comment 10•14 years ago
|
||
Using Mozilla/5.0 (Windows NT 5.1; rv:2.0b8) Gecko/20100101 Firefox/4.0b8, I can reproduce this crash on my XP Machine. I am now installing windbg. I will also try turning mjit off on my next run.
http://crash-stats.mozilla.com/report/index/bp-37462576-8000-4aca-a059-44c442110107 is my latest crash.
Reporter | ||
Comment 11•14 years ago
|
||
I now have several minidumps ready to hand off to Luke.
Running the site in Comment 0 live (not locally), I can consistently reproduce crashes on the Win XP QA lab machine using Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20110107 Firefox/4.0b9pre. I don't always get the same stack - the last few stacks show as:
[@ js::StackSpace::mark(JSTracer*) ]
[@ StringCopyWorkerW ]
[@ nsTextFrame::GetTrimmedOffsets(nsTextFragment const*, int) ]
The most recent stacks are here:
http://crash-stats.mozilla.com/report/index/bp-a88d9ebb-97d7-4658-a758-cda522110107
http://crash-stats.mozilla.com/report/index/bp-07351521-d735-4c1f-ae74-632412110107
http://crash-stats.mozilla.com/report/index/bp-056762df-08bd-4efe-810f-d86802110107
http://crash-stats.mozilla.com/report/index/bp-0d921116-0ffd-42cc-aeb3-450ad2110107
Reporter | ||
Comment 12•14 years ago
|
||
I just did another run with methodjit pref'd off and still crashed. Same STR in Comment 11.
Reporter | ||
Comment 13•14 years ago
|
||
I put the dump files here: http://fs/public/Users/marcia/
Assignee | ||
Comment 14•14 years ago
|
||
Opening these crash dumps in MSVC shows all the symbols loaded correctly, but it shows only 1 thread that is under exit() called from main(). Perhaps these dumps are not being captured from the right FF process?
Assignee | ||
Comment 15•14 years ago
|
||
Update: suspecting anti-virus software installed on XP machine. Also, crashes seem to be at different locations each time. Will try on anti-virus-free image and go from there.
Comment 16•14 years ago
|
||
(In reply to comment #15)
> Update: suspecting anti-virus software installed on XP machine. Also, crashes
> seem to be at different locations each time. Will try on anti-virus-free image
> and go from there.
mz's indidicated in the meta bug that introducing the network into the testing creates more randomness in the results. See: https://bugzilla.mozilla.org/show_bug.cgi?id=623189#c11 I'm guessing that network, plus any AV adds to the randomness of results.
We should be doing all the testing off a local copy and using the latest fuzzer files, and using controlled seed values to create the best chances for creating reproducible test cases.
Assignee | ||
Comment 17•14 years ago
|
||
Unblocking until we can get something reproducible; also the crash address from the fuzzer seems highly variable.
blocking2.0: betaN+ → .x
Assignee | ||
Comment 18•14 years ago
|
||
There were related fixes in FF4 that may have been for the same underlying bug as this. Either way, this doesn't seem to have reproduced.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Comment 19•14 years ago
|
||
There seemed to be something here as evidenced by crash stacks. "worksforme" is better for things that seem to have fixed themselves, "invalid" is for things that weren't bugs in the first place.
blocking2.0: .x+ → ---
Resolution: INVALID → WORKSFORME
Comment 20•14 years ago
|
||
unconfirming and maybe removing security sensitive status could help moving to something reproducible. how much risk would there be in opening the bug?
Assignee | ||
Comment 21•14 years ago
|
||
Opening seems fine to me. Any STR for these StackSpace::* crashes would be most welcome.
Updated•14 years ago
|
Crash Signature: [@ js::StackSpace::pushSegmentForInvoke(JSContext*, unsigned int, js::InvokeArgsGuard*) ]
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Keywords: testcase-wanted
Updated•9 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•