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

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.

Wow, I am able to get plenty of crashes, just not pushSegmentForInvoke. I'll keep trying.

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

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.

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.)

It'd be good to attach a testcase to the bug just in case lcamtuf's online fuzzer changes over time.

Does this crash reproduce if the mjit is turned off?

Better instructions for just getting the minidump: https://developer.mozilla.org/User:Shaver/Capturing_a_minidump

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.

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.

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

I just did another run with methodjit pref'd off and still crashed. Same STR in Comment 11.

I put the dump files here: http://fs/public/Users/marcia/

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?

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.

(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.

Unblocking until we can get something reproducible; also the crash address from the fuzzer seems highly variable.

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.

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.

unconfirming and maybe removing security sensitive status could help moving to something reproducible. how much risk would there be in opening the bug?

Opening seems fine to me. Any STR for these StackSpace::* crashes would be most welcome.