Closed Bug 398265 Opened 14 years ago Closed 14 years ago

Crash [@ nsPrintPreviewListener::RemoveListeners()] with <frame> on print preview


(Core :: Print Preview, defect, P2)

Windows XP





(Reporter: martijn.martijn, Assigned: smaug)


(Keywords: crash, regression, testcase)

Crash Data


(3 files)

Attached file testcase
See testcase, when doing print preview on that testcase, I crash with current trunk build after clicking away the "An unknown error occured while printing" dialogs.

This seems to have regressed between 2007-07-01 and 2007-07-02:
I have no idea what might have caused this.
0  	nsPrintPreviewListener::RemoveListeners()  	 mozilla/layout/printing/nsPrintPreviewListener.cpp:100
1 	nsPrintData::~nsPrintData() 	mozilla/layout/printing/nsPrintData.cpp:96
2 	nsPrintEngine::CommonPrint(int, nsIPrintSettings*, nsIWebProgressListener*) 	mozilla/layout/printing/nsPrintEngine.cpp:429
3 	nsPrintEngine::PrintPreview(nsIPrintSettings*, nsIDOMWindow*, nsIWebProgressListener*) 	mozilla/layout/printing/nsPrintEngine.cpp:720
4 	DocumentViewerImpl::PrintPreview(nsIPrintSettings*, nsIDOMWindow*, nsIWebProgressListener*) 	mozilla/layout/base/nsDocumentViewer.cpp:3513
5 	NS_InvokeByIndex_P 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
6 	AutoJSSuspendRequest::SuspendRequest() 	mozilla/js/src/xpconnect/src/xpcprivate.h:3318
7 	RtlpAllocateFromHeapLookaside
Flags: blocking1.9?
Severity: normal → critical
Flags: blocking1.9? → blocking1.9+
This will fix the crash from happening.  We still end up with an "Unknown print error"
Attachment #286005 - Flags: review?(roc)
Priority: -- → P2
Target Milestone: --- → mozilla1.9 M10
Where is the mPrintEngine being dropped? If it's because the nsDocumentViewer is going away, then we have more serious problems that could make us crash in other ways...
I can investigate this.
Assignee: nobody → Olli.Pettay
Attachment #286005 - Flags: review?(roc)
Attached patch proposed patchSplinter Review
I think we want this.
The problem is that we're cleaning up things twice.
One crash goes like this: 
DocumentReadyForPrinting() fails, so FinishPrintPreview() calls 
CleanupOnFailure, which fires nsPrintCompletionEvent/nsRunnable. Then before 
the event is handled, DoCommonPrint returns to CommonPrint which open notices 
the error and opens a dialog. Events get processed, and so 
nsPrintCompletionEvent calls mDocViewerPrint->OnDonePrinting(), which deletes 
the printengine. So next time printengine is used, it is a deleted object.

The patch changes things so that FinishPrintPreview() doesn't call 
CleanupOnFailure. It is up to caller to handle clean-up.
FinishPrintPreview() is called 3 times. One is the case here, where we don't 
want CleanupOnFailure() to be called, one is in ::Observe(), which I'm changing 
in the patch and one is in nsDocumentViewerImpl::Destroy, where printengine is 
anyway destroyed, so doesn't make much sense to clean-up (and possibly show a dialog).
Not sure, but this might be actually a regression from Bug 370966.
Attachment #288040 - Flags: superreview?(roc)
Attachment #288040 - Flags: review?(roc)
Comment on attachment 288040 [details] [diff] [review]
proposed patch

Document that callers to FinishPrintPreview are expected to clean up.
Attachment #288040 - Flags: superreview?(roc)
Attachment #288040 - Flags: superreview+
Attachment #288040 - Flags: review?(roc)
Attachment #288040 - Flags: review+
Closed: 14 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b2pre) Gecko/2007112905 Minefield/3.0b2pre. I don't crash, but I still get the unknown print error on Win XP.
I filed bug 468843 for the unknown print error thing.
Crash Signature: [@ nsPrintPreviewListener::RemoveListeners()]
You need to log in before you can comment on or make changes to this bug.