Bug 67579

So, using gdb I skipped that assert *once* and then ran again in gdb.

Now that assert succeeds because m_Parent->m_aJobData.m_nPDFDevice==1.

However, when I dismiss the properties page (click "OK"), I ultimately get into this code:

padmin::RTSDialog::ClickButton



        if( m_pDevicePage )
        {
            m_aJobData.m_nColorDepth    = m_pDevicePage->getDepth();
            m_aJobData.m_nColorDevice   = m_pDevicePage->getColorDevice();
            m_aJobData.m_nPSLevel       = m_pDevicePage->getLevel();
            m_aJobData.m_nPDFDevice     = m_pDevicePage->getPDFDevice();
        }


This sets m_aJobData.m_nPDFDevice to 0, but well after the assert. So in a nutshell, I cannot reproduce anymore.


Let's look at the .odt file... settings.xml contains:


<office:document-settings>
  <office:settings>
        <config:config-item-set config:name="ooo:configuration-settings">
            <config:config-item config:name="PrinterSetup" config:type="base64Binary">

And (decoded), this contains:

 pslevel=0
 pdfdevice=0

Aha. So let's try to restart the LibreOffice process on the same file...


More analysis / notes:

m_pParent->m_aJobData seems to be essentially constructed in PspSalInfoPrinter::Setup (file vcl/generic/print/genprnpsp.cxx).

In this case, since pJobSetup->mpDriverData is not NULL, we go into SetData( ~0, pJobSetup ), which calls JobData::constructFromStreamBuffer.

JobData::constructFromStreamBuffer *does* set m_nPDFDevice to 1.

SetData then goes on to create a new StreamBuffer from the information, and returns to PspSalInfoPrinter::Setup, which calls ... JobData::constructFromStreamBuffer again on the StreamBuffer with same contents as the one that SetData worked on, which thus *also* sets m_nPDFDevice to 1.

So we enter Sal_SetupPrinterDriver (file padmin/source/prtsetup.cxx) with a rJobData that has m_nPDFDevice==1, which creates a padmin::RTSDialog passing it the same rJobData; that class copies it into its m_aJobData.

Yup, if I restart LibreOffice, I get the assertion failure again. So it seems that LibreOffice trusts settings.xml "too much".

In a run where the assert happens:

In PspSalInfoPrinter::Setup, before the call to SetData:

gdb) print (char*)pJobSetup->mpDriverData
$95 = 
    0x299e9b0 "JobData 1\nprinter=C353\norientation=Portrait\ncopies=1\nmargindajustment=0,0,0,0\ncolordepth=24\npslevel=0\npdfdevice=0\ncolordevice=0\nPPDContexData\nInputSlot:Tray1"


So, the pdfdevice=0 from settings.xml somehow gets there. Not sure why / how; that setting seems like it is printer-dependent to me. Why would it be trusted from an .odt (and why it is saved there in the first place), I'm not completely sure, since the printer environment may have changed since the file was saved. It may even be a different printer.

From there, it trickles down to RTSDialog's m_aJobData and triggers the assert.

When creating a new file, I cannot reproduce the "pdfdevice=0" setting being included. It must have been inherited from a save with an older version of LibreOffice.

Manually emptying PrinterSetup in settings.xml fixes the crash.

The assert-failure-inducing "pdfdevice=0" survives:

 - file / save as
 - 'print directly' from toolbar then file / save
 - 'print' (dialog) / OK, then file / save

It does not survive:

 - print (dialog), select other printer, select default printer again,
   OK (it prints), then file / save

Hmmm... This seems extremely related to the situation / scenario described in bug 58080. My guess:

In bug 58080, the "Generic Printer" business pollutes the "pdfdevice" setting (in memory) and puts 0 there. Then I save the file (in bug 58080, the assert fails only the second time the print dialog is opened).

After printing the file *once* in the "Generic Printer" situation, I saved the file, which saved the bad "pdfdevice=0" in the file, leading to this bug.