1429707 - Crash in mozilla::ipc::LogicError | mozilla::layout::PRemotePrintJobChild::SendFinalizePrint

Status: RESOLVED DUPLICATE of bug 1432409

(Core :: Printing: Setup, defect, P3)

Description

[Mantaroh Yoshinaga[:mantaroh]]

This bug was filed from the Socorro interface and is
report bp-644334f8-3dd4-4219-8116-d55340180111.
=============================================================

Top 10 frames of crashing thread:

0 libmozglue.dylib MOZ_CrashOOL mfbt/Assertions.cpp:33
1 XUL mozilla::ipc::LogicError ipc/glue/ProtocolUtils.cpp:306
2 XUL mozilla::layout::PRemotePrintJobChild::SendFinalizePrint ipc/ipdl/PRemotePrintJob.cpp:37
3 XUL nsDeviceContextSpecProxy::EndDocument widget/nsDeviceContextSpecProxy.cpp:150
4 XUL nsDeviceContext::EndDocument gfx/src/nsDeviceContext.cpp:553
5 XUL nsPrintData::~nsPrintData layout/printing/nsPrintData.cpp:83
6 XUL nsPrintJob::Destroy layout/printing/nsPrintData.cpp:61
7 XUL nsDocumentViewer::OnDonePrinting layout/base/nsDocumentViewer.cpp:4557
8 XUL nsPrintCompletionEvent::Run layout/printing/nsPrintJob.cpp:3546
9 XUL mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:395

=============================================================

STR:
 1) Set print.always_print_silent=true (Automation test uses this preference.)
 2) Print content.

Note:
 Several user uses this preference for printing. (see bug 1426343)

Comment 1

[Mantaroh Yoshinaga[:mantaroh]]

I can reproduce this crash on Linux and I can prevent this crash remove following code:
https://hg.mozilla.org/mozilla-central/rev/c85b83645bb3#l3.17

Comment 2

[Andrew Overholt [:overholt]]

Would be great to have a regression range here.

Comment 3

[Marcia Knous [:marcia]]

Initial crash from reporter on Mac is Build 20180108220132 when Nightly was in 59 (I couldn't reproduce on Mac). Since then I do see crashes on Windows as well.

Mantaroh can you help with a regression range?

Comment 4

[Mantaroh Yoshinaga[:mantaroh]]

(In reply to Marcia Knous [:marcia - use ni] from comment #3)
> Initial crash from reporter on Mac is Build 20180108220132 when Nightly was
> in 59 (I couldn't reproduce on Mac). Since then I do see crashes on Windows
> as well.
> 
> Mantaroh can you help with a regression range?

Umm, macOS and Linux different regression range.

Mac is Here :
14:59.44 INFO: Last good revision: 79f23b8d3f2b6a77635bb93100ac28af7a9a9148
14:59.44 INFO: First bad revision: f1dd3438f8b526886bad0cccec707e30aceb48cc
14:59.44 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=79f23b8d3f2b6a77635bb93100ac28af7a9a9148&tochange=f1dd3438f8b526886bad0cccec707e30aceb48cc

Linux is Here :
6:17.02 INFO: Last good revision: 2a4362ce2d9fa82f62909532a1b534d214761341
6:17.02 INFO: First bad revision: b84fe2ad1ca27fc30c2e3f609b8f766185652560
6:17.02 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2a4362ce2d9fa82f62909532a1b534d214761341&tochange=b84fe2ad1ca27fc30c2e3f609b8f766185652560

Comment 5

[Mantaroh Yoshinaga[:mantaroh]]

I can reproduce this phenomenon with several addons. (Windows 10 / Windows 7 / Linux

STR:
 1) Install addon which uses a saveAsPDF. (e.g. Print to PDF)
 2) Load contents which take a few seconds for loading contents. (e.g. bcc.com)
 3) Call a saveAsPDF before loading content is finished.
 4) Click the save button of dialog that is displayed after finishing content loading.
 5) Call a saveAsPDF again.

I guess gecko need to prevent calling a saveAsPDF before loading content is completed.

Comment 6

[Mantaroh Yoshinaga[:mantaroh]]

(In reply to Mantaroh Yoshinaga[:mantaroh] from comment #5)
> I can reproduce this phenomenon with several addons. (Windows 10 / Windows 7
> / Linux

Oh, Sorry.
I can reproduce on Windows machines(7 and 10).
A current implementation uses a print() function with silent mode[1], I guess a silent mode might have a potential bug. I'll look into this for a little further.

[1] https://searchfox.org/mozilla-central/rev/f80722d4f3bfb722c5ec53880c4a7efb71285676/browser/components/extensions/ext-tabs.js#946,1036

Comment 7

[Mantaroh Yoshinaga[:mantaroh]]

(In reply to Mantaroh Yoshinaga[:mantaroh] from comment #6)
> (In reply to Mantaroh Yoshinaga[:mantaroh] from comment #5)
> > I can reproduce this phenomenon with several addons. (Windows 10 / Windows 7
> > / Linux
> 
> Oh, Sorry.
> I can reproduce on Windows machines(7 and 10).
> A current implementation uses a print() function with silent mode[1], I
> guess a silent mode might have a potential bug. I'll look into this for a
> little further.
> 
> [1]
> https://searchfox.org/mozilla-central/rev/
> f80722d4f3bfb722c5ec53880c4a7efb71285676/browser/components/extensions/ext-
> tabs.js#946,1036

We can call the saveAsPDF() before a document is loaded. If we call in this situation, the gecko will pend the print operation[1]. And gecko will continue print operation after loading document is completed.[2]

[1] https://searchfox.org/mozilla-central/rev/84cea84b12145d752e50ddca6be5462c38510e35/layout/base/nsDocumentViewer.cpp#3869
[2] https://searchfox.org/mozilla-central/rev/84cea84b12145d752e50ddca6be5462c38510e35/layout/base/nsDocumentViewer.cpp#1127

TabChild::RecvPrint() create the PrintSession, however, this instance will live in this function. If we call saveAsPDF function before loading document is not completed, the gecko will wait for loading document and destroy this print session. As result of it, the gecko will display a native print dialog, then print by using previous referenced print session after loading content is finished.

Comment 8

[Mantaroh Yoshinaga[:mantaroh]]

(In reply to Mantaroh Yoshinaga[:mantaroh] from comment #7)
> (In reply to Mantaroh Yoshinaga[:mantaroh] from comment #6)
> > (In reply to Mantaroh Yoshinaga[:mantaroh] from comment #5)
> > > I can reproduce this phenomenon with several addons. (Windows 10 / Windows 7
> > > / Linux
> > 
> > Oh, Sorry.
> > I can reproduce on Windows machines(7 and 10).
> > A current implementation uses a print() function with silent mode[1], I
> > guess a silent mode might have a potential bug. I'll look into this for a
> > little further.
> > 
> > [1]
> > https://searchfox.org/mozilla-central/rev/
> > f80722d4f3bfb722c5ec53880c4a7efb71285676/browser/components/extensions/ext-
> > tabs.js#946,1036
> 
> We can call the saveAsPDF() before a document is loaded. If we call in this
> situation, the gecko will pend the print operation[1]. And gecko will
> continue print operation after loading document is completed.[2]
> 
> [1]
> https://searchfox.org/mozilla-central/rev/
> 84cea84b12145d752e50ddca6be5462c38510e35/layout/base/nsDocumentViewer.
> cpp#3869
> [2]
> https://searchfox.org/mozilla-central/rev/
> 84cea84b12145d752e50ddca6be5462c38510e35/layout/base/nsDocumentViewer.
> cpp#1127
> 
> TabChild::RecvPrint() create the PrintSession, however, this instance will
> live in this function. If we call saveAsPDF function before loading document
> is not completed, the gecko will wait for loading document and destroy this
> print session. As result of it, the gecko will display a native print
> dialog, then print by using previous referenced print session after loading
> content is finished.

For detail, the gecko will create new print settings and new print session since gecko can't reference destroyed print session pointer. So gecko will display the native print dialog due to create new print settings.
If set the print.always_print_silent=true, I can't reproduce this bug.

Comment 9

[Jonathan Watt [:jwatt]]

There's only one crash is b7 and one in b8. It looks like the fix for one of the other printing bugs that landed in b7 mostly fixed this.

Comment 10

[Jet Villegas (inactive)]

[ Triage 2017/02/20: P3 ]

Comment 11

[Mantaroh Yoshinaga[:mantaroh]]

I confirmed that this phenomenon doesn't appear after landing the patch of bug 1432409 in my environment.
I think that this crash related with the bug 1432409 comment 9.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Fixed in the duplicate.