flypig.co.uk

Over the last couple of days I've been looking into the printing stack, so that the new browser version will support the "Print to PDF" feature of sailfish-browser. There have been some changes to the print setup pipeline and the latest situation is that the page appears to need to be cloned before it can be printed, but currently that's not happening.

Yesterday I came to the conclusion however that the code is similar enough to that in ESR 78 that I might be able to figure out the parts that are missing by stepping through both side-by-side in the debugger. So that's my task for today.

I've set up both phones with an ssh connection into both from my laptop. I'm debugging ESR 78 on one and ESR 91 on the other using gdb. I'm particularly interested in four points in the code which I've attached breakpoints to:

(gdb) info break
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   <PENDING>  Document::CreateStaticClone
2       breakpoint     keep y   <PENDING>  Document::CloneDocHelper
3       breakpoint     keep y   <PENDING>  nsPrintObject::InitAsRootObject
4       breakpoint     keep y   <PENDING>  nsPrintJob::FindFocusedDOMWindow

Unfortunately debugging the regular ESR 78 install proves to be harder than I'd expected — which is odd because it's not the first time I've done it — as it just crashes out when attaching the breakpoint.

(gdb) b Document::CreateStaticClone
dwarf2read.c:10473: internal-error: process_die_scope::process_die_scope
    (die_info*, dwarf2_cu*): Assertion `!m_die->in_process' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

I've tried reinstalling the browser and debug packages but that didn't help. I've rebooted my phone and that didn't help. I've even tried debugging on a different phone. None of these provides a solution. This feels like it's been a bit of a wild goose chase.

It does at least only seem to apply to certain breakpoints:

Thread 1 "sailfish-browse" received signal SIGINT, Interrupt.
0x0000007fef978718 in pthread_cond_wait () from /lib64/libpthread.so.0
(gdb) b nsPrintJob::FindFocusedDOMWindow
Breakpoint 1 at 0x7ff4501dd0: file layout/printing/nsPrintJob.cpp, line 2606.
(gdb) b nsPrintObject::InitAsRootObject
Breakpoint 2 at 0x7ff4508ab0: file layout/printing/nsPrintObject.cpp, line 165.
(gdb) Document::CloneDocHelper
Undefined command: "Document".  Try "help".
(gdb) b Document::CloneDocHelper
dwarf2read.c:10473: internal-error: process_die_scope::process_die_scope
    (die_info*, dwarf2_cu*): Assertion `!m_die->in_process' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y

Okay, so I'll just go with the ones that don't destroy the debugger.

I've studiously added them, carefully avoiding the destructive ones, let's see if either of these get hit.

(gdb) info break
Num Type       Disp Enb Address            What
1   breakpoint keep y   0x0000007ff4501dd0 in nsPrintJob::FindFocusedDOMWindow() const 
                                           at layout/printing/nsPrintJob.cpp:2606
2   breakpoint keep y   0x0000007ff4508ab0 in nsPrintObject::InitAsRootObject
                                           (nsIDocShell*, mozilla::dom::Document*, bool) 
                                           at layout/printing/nsPrintObject.cpp:165

One of them does hit, but it's the uninteresting one; the one I knew was going to hit.

Thread 10 "GeckoWorkerThre" hit Breakpoint 1, nsPrintJob::FindFocusedDOMWindow
    (this=this@entry=0x7fb9491bc0)
    at layout/printing/nsPrintJob.cpp:2606
2606	already_AddRefed<nsPIDOMWindowOuter>
        nsPrintJob::FindFocusedDOMWindow() const {

When I re-run with just the a single breakpoint on nsPrintObject::InitAsRootObject() I find it does hit, but frustratingly id then triggers the same problem as before, preventing me from getting a backtrace:

Thread 10 "GeckoWorkerThre" hit Breakpoint 1, nsPrintObject::InitAsRootObject
    (this=0x7fb872cee0, aDocShell=0x7fb8ceb560, aDoc=aDoc@entry=
dwarf2read.c:10473: internal-error: process_die_scope::process_die_scope
    (die_info*, dwarf2_cu*): Assertion `!m_die->in_process' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
<http://www.gnu.org/software/gdb/bugs/>.

So I've gone back to debugging ESR 91 without reference to ESR 78. There the breakpoints are at least working without causing the debugger to crash.

I notice that nsPrintJob::Initialize() is being hit. This is important because in ESR 78 I think this is where the clone is happening (although due to my failed debugging experience I don't know for sure). I have an ESR 91 backtrace:

Thread 8 "GeckoWorkerThre" hit Breakpoint 7, nsPrintJob::Initialize
    (this=this@entry=0x7f89255bb0, aDocViewerPrint=0x7f891b05e0,
    aDocShell=0x7f88630188, aOriginalDoc=0x7f891a24d0, aScreenDPI=288) at
    layout/printing/nsPrintJob.cpp:383
383                                     float aScreenDPI) {
(gdb) bt
#0  nsPrintJob::Initialize (this=this@entry=0x7f89255bb0,
    aDocViewerPrint=0x7f891b05e0, aDocShell=0x7f88630188,
    aOriginalDoc=0x7f891a24d0, aScreenDPI=288)
    at layout/printing/nsPrintJob.cpp:383
#1  0x0000007fbc108fb0 in nsDocumentViewer::Print (this=0x7f891b05d0,
    aPrintSettings=0x7e2cf1be70, aWebProgressListener=0x7e24b5e420)
    at ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsDeviceContext.h:88
#2  0x0000007fb9cb2e9c in _NS_InvokeByIndex () at xpcom/reflect/xptcall/md/unix/
    xptcinvoke_asm_aarch64.S:74
[...]
#32 0x0000007fbd16635c in js::jit::MaybeEnterJit (cx=0x7f88234da0, state=...)
    at js/src/jit/Jit.cpp:207
#33 0x0000007f8830db51 in ?? ()
Backtrace stopped: Cannot access memory at address 0x88d65bb3f780
(gdb) 

I might come back to this debugging, but right now I need a break from it. So I'll spend a bit of time following up the differences between ESR 78 and ESR 91 through changesets instead.

This has been a frustrating experience today.

But despite all this failure I do feel like I'm gradually building up a clearer picture of how things are supposed to work. With any luck that means I'm getting closer to figuring out what the underlying issue is.

If you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.