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)

1.7 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: bmo, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

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
nope.. i was just hitting ctrl-T over and over to get tons of new tabs.

marc
Summary: crash when windows runs out of some mysterious resource → crash when windows runs out of some mysterious resource [@ DocumentViewerImpl::InstallNewPresentation ]
Is this a problem on trunk?
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/
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
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 → ---
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → WORKSFORME
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.
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...
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
Marc, does the problem still occur in Firefox 1.5.0.12/2.0.0.4 or newer?
Whiteboard: CLOSEME 2007-08-14
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 ago17 years ago
Resolution: --- → INCOMPLETE
Whiteboard: CLOSEME 2007-08-14
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 → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image screenshot
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.
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 :)
Assignee: printing → nobody
QA Contact: printing
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 ago15 years ago
Resolution: --- → INCOMPLETE
Crash Signature: [@ DocumentViewerImpl::InstallNewPresentation ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: