Bug 115221 - PRINTING: CRASH immediately after choosing comment (+doc) printing in the print dialog
Summary: PRINTING: CRASH immediately after choosing comment (+doc) printing in the pri...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: All All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:6.0.1
Keywords: bibisected, bisected, haveBacktrace, regression
: 115402 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-25 08:56 UTC by Tobias Burnus
Modified: 2018-02-02 14:42 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SwViewShell::GetPostItMgr()"]


Attachments
gdb backtrace (39.25 KB, text/plain)
2018-01-25 10:49 UTC, Xisco Faulí
Details
bt with debug symbols (14.82 KB, text/plain)
2018-01-25 14:36 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2018-01-25 08:56:41 UTC
The following occurs with both
6.0.0.1 on Windows 7 (32bit) and
6.1.0.0.alpha0+
Build ID: 0074951704022d173a5fdb9df933f47be1dcbb91
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-10_01:01:50


Try:

1. Open Writer with a new (empty) document

2. Insert -> Comment
   (a yellow comment box is shown right of the page edge,
    if you want, type something it it)

3. File -> Print...

4. At the bottom center in "Comments:" one has
   - None (document only)     [-> OK]
   - Comments only            [-> OK]
   - Place at end of document [-> CRASH]
   - Place at end of page     [-> CRASH]
   - Place in margins         [-> CRASH]

Choosing one of those marked with CRASH causes LibreOffice immediately to crash.
Comment 1 Mike Kaganski 2018-01-25 09:38:36 UTC
Reproduced with Version: 6.0.0.2 (x64)
Build ID: 06b618bb6f431d27fd2def25aa19c833e29b61cd
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: 

and with Version: 6.1.0.0.alpha0+ (x64)
Build ID: de1bb0878fc7d7eb6071ec94d770712648013075
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: ru-RU (ru_RU); Calc: CL
Comment 2 Xisco Faulí 2018-01-25 10:49:48 UTC
Created attachment 139357 [details]
gdb backtrace
Comment 3 Xisco Faulí 2018-01-25 11:05:25 UTC
Regression introduced by:

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-10-04 13:30:11 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-10-05 13:49:22 +0200
commit	cc483d0470dbf0d01e4da818b148ff0b851c5187 (patch)
tree	8775e63c99cca6d0d44c0f2820d859691edb4cfa
parent	74977861a63c920f9b49e90087cac9a841392729 (diff)
tdf#112292 - fix memory leak and use more auto ref counting in sw
this bug was introduced in

    commit a754294ac7a902fe96fbbd6b8b6824a360d6b248
    use rtl::Reference in SwDocFac instead of manual acquire/release

fix it by using automatic ref-counting (i.e. rtl::Reference) everywhere.

Note that the logic in SwViewShell::~SwViewShell is somewhat
interesting.
From my reading of it, it was previously potentially calling
getIDocumentLayoutAccess on an SwDoc that had just been deleted.

So if there is a problem with this commit I would look there first.

Bisected with: bibisect-linux64-6.0

Adding Cc: to Noel Grandin
Comment 4 Julien Nabet 2018-01-25 14:36:27 UTC
Created attachment 139362 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this.

I noticed that it crashes when you change "Comments" a second time.
Indeed, for the test I chose first "Place at end of document", no crash, then I selected "Comments only" and it crashed.
Comment 5 Julien Nabet 2018-01-25 15:33:44 UTC
Noel: this part seems weird to me:
@@ -322,14 +322,11 @@ SwViewShell::~SwViewShell()
         delete mpImp; // Delete first, so that the LayoutViews are destroyed.
         mpImp = nullptr;   // Set to zero, because ~SwFrame relies on it.
 
-        if ( mpDoc )
+        if ( mxDoc.get() )
         {
-            if( !mpDoc->release() )
-            {
-                delete mpDoc;
-                mpDoc = nullptr;
-            }
-            else
+            auto x = mxDoc->getReferenceCount();
+            mxDoc.clear();
+            if( x > 1 )
                 GetLayout()->ResetNewLayout();
         }

Indeed, with mxDoc, we don't call acquire anymore, so getReferenceCount is never > 1 + we shouldn't call clear() on mxDoc manually, should we?

I thought about this patch then:
diff --git a/sw/source/core/view/vnew.cxx b/sw/source/core/view/vnew.cxx
index 2998ffb131f8..6ae4f8a07a62 100644
--- a/sw/source/core/view/vnew.cxx
+++ b/sw/source/core/view/vnew.cxx
@@ -324,10 +324,7 @@ SwViewShell::~SwViewShell()
 
         if ( mxDoc.get() )
         {
-            auto x = mxDoc->getReferenceCount();
-            mxDoc.clear();
-            if( x > 1 )
-                GetLayout()->ResetNewLayout();
+            GetLayout()->ResetNewLayout();
         }
 
         delete mpOpt;
what do you think?
Comment 6 Mike Kaganski 2018-01-25 17:49:27 UTC
(In reply to Julien Nabet from comment #5)

The destroying viewshell gets used in the update sequence, and so its partially destroyed data is being accessed. The problem here IMO is how to ensure that it doesn't get involved in the update sequence (deregister it somewhere prior to the clearing the mxDoc?).
Comment 7 Julien Nabet 2018-01-25 18:21:50 UTC
(In reply to Mike Kaganski from comment #6)
> (In reply to Julien Nabet from comment #5)
> 
> The destroying viewshell gets used in the update sequence, and so its
> partially destroyed data is being accessed. The problem here IMO is how to
> ensure that it doesn't get involved in the update sequence (deregister it
> somewhere prior to the clearing the mxDoc?).

Seeing the bt:
frame 15:
    328             mxDoc.clear();
frame 2:
   2549     SwView* pView =  GetDoc()->GetDocShell() ? GetDoc()->GetDocShell()->GetView() : nullptr;

It seems indeed the call to clear() which triggers the pb.
Comment 8 Mike Kaganski 2018-01-25 19:37:18 UTC
(In reply to Julien Nabet from comment #7)

Of course. And the clear() (in the second time!) actually deletes the document... should it do that at all? and when it does, shouldn't it have removed itself from some listeners list beforehand, to not receive events initiated bu that document's destruction?
Comment 9 Michael Meeks 2018-01-26 09:12:26 UTC
Patch under discussion at https://gerrit.libreoffice.org/#/c/48658
Comment 10 Commit Notification 2018-01-27 18:34:01 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=de9bcd167b059e00818304626c0cadaa330738a4

tdf#115221 crash in printing and comment

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Tobias Burnus 2018-01-29 19:11:00 UTC
Testing with master looks good - except that I observe bug 115302.
Comment 12 Tobias Burnus 2018-01-30 09:04:20 UTC
(In reply to Tobias Burnus from comment #11)
> Testing with master looks good - except that I observe bug 115302.

Testing a bit more, I STILL get a CRASH:

If I hit [OK] in the print dialog, LibreOffice now crashes. You simply need to do

1. Create new document
2. File | Print
3. [OK]

That's with: Version: 6.1.0.0.alpha0+
Build ID: 85b3c799ede62a3d7ad0493fc80b629214956601
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-29_05:58:14
Locale: en-US (en_US); Calc: CL
Comment 13 Noel Grandin 2018-01-30 09:25:30 UTC
Julien, looks like the crash in comment 12 was introduced by

commit 85b3c799ede62a3d7ad0493fc80b629214956601
Author: Julien Nabet <serval2412@yahoo.fr>
Date:   Sun Jan 28 22:46:46 2018 +0100

    Modernize a bit vcl (part2)

where the group variable is now not being initialised at all
Comment 14 Julien Nabet 2018-01-30 09:27:02 UTC
Thank you Noel, I'll take this.
Comment 15 Julien Nabet 2018-01-30 09:37:17 UTC
I could reproduce the crash:
#4  0x00007fffec187907 in vcl::SettingsConfigItem::ImplCommit() (this=0x5555576db0a0) at /home/julien/lo/libreoffice/vcl/source/gdi/configsettings.cxx:66
#5  0x00007fffed0865d5 in utl::ConfigItem::Commit() (this=0x5555576db0a0) at /home/julien/lo/libreoffice/unotools/source/config/configitem.cxx:1127
#6  0x00007fffebee5776 in vcl::PrintDialog::storeToSettings() (this=0x55555c09a260) at /home/julien/lo/libreoffice/vcl/source/window/printdlg.cxx:789

I had let an iterator in the patch.

I submitted this patch to gerrit.
Comment 16 Julien Nabet 2018-01-30 09:37:40 UTC
https://gerrit.libreoffice.org/#/c/48890/
Comment 17 Commit Notification 2018-01-30 10:26:34 UTC
Noel Grandin committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9e7344ae5776117e94684713767fae1b0afbb6b9&h=libreoffice-6-0

tdf#115221 crash in printing and comment

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 19 Michael Meeks 2018-01-31 15:45:34 UTC
Assuming fixed then =)
Comment 20 Buovjaga 2018-01-31 18:01:03 UTC
I ran into a variant: "Print to file", nothing about comments. Confirmed a fresh build makes the crashing go away.

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: e80da60895b45309fa1d018760d5f11cca4367f4
CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group threaded
Built on January 31st 2018
Comment 21 Xisco Faulí 2018-02-02 14:42:41 UTC
*** Bug 115402 has been marked as a duplicate of this bug. ***