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.
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
Created attachment 139357 [details] gdb backtrace
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
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.
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?
(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?).
(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.
(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?
Patch under discussion at https://gerrit.libreoffice.org/#/c/48658
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.
Testing with master looks good - except that I observe bug 115302.
(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
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
Thank you Noel, I'll take this.
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.
https://gerrit.libreoffice.org/#/c/48890/
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.
(In reply to Julien Nabet from comment #16) > https://gerrit.libreoffice.org/#/c/48890/ Pushed (see https://cgit.freedesktop.org/libreoffice/core/commit/?id=b4f440092b852a7c66f4acdd7e9b0c8e23e212ef)
Assuming fixed then =)
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
*** Bug 115402 has been marked as a duplicate of this bug. ***