Closed
Bug 274959
Opened 20 years ago
Closed 15 years ago
crash when windows runs out of some mysterious resource [@ DocumentViewerImpl::InstallNewPresentation ]
Categories
(Core :: Print Preview, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: bmo, Unassigned)
References
()
Details
(Keywords: crash)
Crash Data
Attachments
(1 file)
|
223.35 KB,
image/png
|
Details |
my machine regularly runs out of some mysterious perhaps gui-related resource after about a week of use. when it does, things like right-clicking in apps fail to produce a menu. apps that chew up a lot of whatever the mystery resource is are the first to choke. this time, i couldn't start up acrobat reader. for kicks, i opened a ton of tabs in firefox because i've been able to consume the myster resource this way. for the first time that i've seen, firefox actually crashed. talkback didn't fire up until i rebooted and restarted firefox. TB2587952Z
Incident ID: 2587952 Stack Signature DocumentViewerImpl::InstallNewPresentation 13bbf09d Product ID Firefox10 Build ID 2004110711 Trigger Time 2004-12-16 12:33:19.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (0019559f) URL visited User Comments i shut the machine down cleanly and then rebooted. as soon as i fired up firefox, talkback came up... Since Last Crash 1118809 sec Total Uptime 1118809 sec Trigger Reason Access violation Source File, Line No. d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp, line 3873 Stack Trace DocumentViewerImpl::InstallNewPresentation [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp, line 3873] nsPrintEngine::FinishPrintPreview [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsPrintEngine.cpp, line 4498] nsPrintEngine::PrintPreview [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsPrintEngine.cpp, line 1258] DocumentViewerImpl::PrintPreview [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/content/base/src/nsDocumentViewer.cpp, line 3250] XPTC_InvokeByIndex [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp, line 102] XPCWrappedNative::CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2034] XPC_WN_CallMethod [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1287] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 941] js_Interpret [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 2978] js_Invoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 958] js_InternalInvoke [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1035] JS_CallFunctionValue [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line 3698] nsJSContext::CallEventHandler [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1297] GlobalWindowImpl::RunTimeout [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5350] GlobalWindowImpl::TimerCallback [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp, line 5712] nsAppShellService::Run [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 495] main [d:/builds/tinderbox/firefox-1.0/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp, line 58] kernel32.dll + 0x16d4f (0x7c816d4f) were you print previewing?
Assignee: firefox → core.printing
Component: General → Print Preview
Keywords: crash
Product: Firefox → Core
QA Contact: firefox.general
Version: 1.0 Branch → 1.7 Branch
| Reporter | ||
Comment 2•20 years ago
|
||
nope.. i was just hitting ctrl-T over and over to get tons of new tabs. marc
Updated•20 years ago
|
Summary: crash when windows runs out of some mysterious resource → crash when windows runs out of some mysterious resource [@ DocumentViewerImpl::InstallNewPresentation ]
Comment 3•20 years ago
|
||
Is this a problem on trunk?
Comment 4•19 years ago
|
||
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Comment 5•19 years ago
|
||
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
| Reporter | ||
Comment 6•19 years ago
|
||
i finally got around to trying this with latest-trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051230 Firefox/1.6a1 not only can i not reproduce this, i can't get any programs to exhibit the old, bad behavior. i'm guessing that XP has been improved in some way since this bug was opened that makes it harder for me to run out of the mystery resource. marking WFM
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
| Reporter | ||
Updated•19 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 7•19 years ago
|
||
it happened again using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1 ID:2006011112 i'll try latest trunk tb: TB16163158Q === Stack Signature xpsp2res.dll + 0x202113 (0x20202113) 717179e8 Product ID Firefox15 Build ID 2006011112 Trigger Time 2006-03-09 16:55:19.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module xpsp2res.dll + (00202113) URL visited http://dev.mysql.com/downloads/mysql/4.1.html User Comments i think this is bug 274959 Since Last Crash 1173364 sec Total Uptime 2718152 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace xpsp2res.dll + 0x202113 (0x20202113) js_InitStringClass [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsstr.c, line 2505] nsWindowSH::NewResolve [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 5526] XPC_WN_Helper_NewResolve [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1063] js_LookupPropertyWithFlags [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2710] js_FindConstructor [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2105] GetClassPrototype [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 3837] js_NewObject [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 1985] js_StringToObject [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsstr.c, line 2727] js_ValueToNonNullObject [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 3971] js_Interpret [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5268] js_Invoke [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1197] js_InternalInvoke [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1274] JS_CallFunctionValue [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 4158] nsXBLProtoImplAnonymousMethod::Execute [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLProtoImplMethod.cpp, line 339] nsXBLBinding::ExecuteAttachedHandler [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLBinding.cpp, line 788] PresShell::InitialReflow [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 2829] nsContentSink::StartLayout [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/content/base/src/nsContentSink.cpp, line 924] HTMLContentSink::StartLayout [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3562] CNavDTD::HandleDefaultStartToken [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1283] CNavDTD::HandleStartToken [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 1668] CNavDTD::HandleToken [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 955] CNavDTD::BuildModel [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/CNavDTD.cpp, line 458] nsParser::BuildModel [c:/builds/tinderbox/Fx-Mozilla1.8.0/WINNT_5.2_Depend/mozilla/parser/htmlparser/src/nsParser.cpp, line 2132] ===
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
so um. the original crash is very much a gui resource concern. the new crash is an unrelated javascript core resource concern. i'd rather you not reopen this bug for that problem. also note that there are crash reports for the stack you've pasted this time, so don't just file a new bug, do search.
| Reporter | ||
Comment 9•19 years ago
|
||
i can't get latest trunk (Firefox 1.6a1 ID:2006030908) to crash, but it does become unusable when this mystery resource runs out. new tabs are blank and don't fill in. right-click doesn't give you a menu. file, edit, etc menus don't drop down when you click, etc...
| Reporter | ||
Comment 10•19 years ago
|
||
so i guess i coincidentally crashed when i hit bug 328787, but my machine is definitely in the state it was when this original report was opened. whatever GUI resource it is that i'm running out of, it would be great if firefox reported it instead of just misbehaving. any clues? tia, marc
Comment 11•17 years ago
|
||
Marc, does the problem still occur in Firefox 1.5.0.12/2.0.0.4 or newer?
Whiteboard: CLOSEME 2007-08-14
Comment 12•17 years ago
|
||
Due to lack of reporter feedback and the inability to reproduce this bug, it is being resolved as INCOMPLETE. Reporter, feel free to reopen this bug if you still are experiencing this issue and wish to provide us with more information so that we can help.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago → 17 years ago
Resolution: --- → INCOMPLETE
| Reporter | ||
Comment 13•17 years ago
|
||
sorry for the delay. just tested with 2.0.0.6 and wasn't able to immediately make it crash, but i did exhaust whatever the mysterious resource is to the point of confusing firefox such that it no longer was painting on tabs. i'm attaching a screenshot showing a completely blank cnn.com tab. fx did suck down all the content, but nothing visible was painted.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
| Reporter | ||
Updated•17 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
| Reporter | ||
Comment 14•17 years ago
|
||
Comment 15•17 years ago
|
||
Marc, screenshot very much appreciated. Could you please post in a comment your steps to reproduce this in as much detail and using the following format: Steps to reproduce: 1. 2. 3. ..... Just to the best of your recollection. This will make it a lot easier for us to diagnose this problem. Also, could you please tell identify what version of windows, what version of Firefox you originally saw this on, any plugins/extensions/themes you are running and their versions. Finally, if you can remember what your update path was to get to 2.0.0.6 (what version you originally installed, what versions you got updated to, any versions you paved over), that would be great. As soon as someone on Mozilla's end can reproduce this bug, the sooner we can create a reliable test case. ** paved over - downloaded the new install file and installed over the old version of Firefox without removing.
| Reporter | ||
Comment 16•16 years ago
|
||
unfortunately, the steps to reproduce aren't easy for others to follow. i open slickedit with tons and tons of buffers while i have eudora open with a zillion mailboxes / messages open. it must be some window-related resource. in any case, i've long ago stopped using windows as my primary OS and don't run into this regularly. i'd be shocked if it doesn't still happen with the latest trunk. to be clear, firefox isn't the only app affected when the XP gets into this state. lots of programs do ungraceful things. i'd bet if you were to script firefox to keep opening windows ad infinitum, you'd hit this bug eventually even without starting out by using tons of the mysterious resource with other applications... either that or you'd hit some constant ceiling on number of open windows that you'd have to tweak to continue :)
Updated•15 years ago
|
Assignee: printing → nobody
QA Contact: printing
Comment 17•15 years ago
|
||
Sounds like Firefox no longer crashes, and does no worse than other apps in this situation. That's about the best anyone can expect, IMO.
Status: NEW → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → INCOMPLETE
| Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ DocumentViewerImpl::InstallNewPresentation ]
You need to log in
before you can comment on or make changes to this bug.
Description
•