Bug Hunting Session
Bug 90956 - LO crashes 100% of attempts to "Export as PDF" from file menu
Summary: LO crashes 100% of attempts to "Export as PDF" from file menu
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Mac OS X (All)
: high critical
Assignee: Not Assigned
URL:
Whiteboard: target:5.0.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: VclPtr
  Show dependency treegraph
 
Reported: 2015-04-30 07:18 UTC by steve -_-
Modified: 2015-12-17 09:00 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF export settings (73.15 KB, image/jpeg)
2015-04-30 07:18 UTC, steve -_-
Details
LO crashlog (66.15 KB, text/plain)
2015-04-30 07:19 UTC, steve -_-
Details

Note You need to log in before you can comment on or make changes to this bug.
Description steve -_- 2015-04-30 07:18:26 UTC
Created attachment 115207 [details]
PDF export settings

OSX 10.10.3 LO Version: 5.0.0.0.alpha1+
Build ID: 2932d2db599c09ecce3faa2d627e9ee4f251183a
TinderBox: MacOSX-10.10@61, Branch:master, Time: 2015-04-29_01:47:02
Locale: de.UTF-8

Reproduce:

1. Start writer
2. without typing anything select from the top menu bar File > Export as PDF... (screenshot of export settings attached)
3. click "export"

Currently: crash
Expected: proper pdf export

Crash log attached as well.
Comment 1 steve -_- 2015-04-30 07:19:56 UTC
Created attachment 115208 [details]
LO crashlog
Comment 2 Alex Thurgood 2015-04-30 08:17:27 UTC
Hi Steve,

I don't get a crash with my own :

Version: 5.0.0.0.alpha1+
Build ID: 950055bcb06c8edcd9062c71184f02bf8e0604e6
Locale : fr_

However, it does take approximately a minute for the Save dialog to appear and in the meantime there is the beachball wait icon. However, this is bug 90913.

No crash for me, no confirmation.
Comment 3 Alex Thurgood 2015-04-30 08:23:18 UTC
Hmm, your test was on a more recent version than mine, let me restest again
Comment 4 Alex Thurgood 2015-04-30 08:56:10 UTC
Confirmed on daily from 30/04/2015

===> regression
Comment 5 Alex Thurgood 2015-04-30 08:57:26 UTC
Confirmed on

Version: 5.0.0.0.alpha1+
Build ID: 0cd88d27ecd87c8c5791418bcac6ab1684ece74a
TinderBox: MacOSX-10.10@61, Branch:master, Time: 2015-04-30_01:56:52
Comment 6 Matthew Francis 2015-05-06 15:56:26 UTC
This began at the below commit.
Adding Cc: to michael.meeks@collabora.com; Could you possibly take a look at this one? Thanks
(Unfortunately this only seems reproducible on OSX, but perhaps you can make sense of the attached backtrace)

commit e8b97a52c96df9c8e8055407b1e40ed7cb9cfc67
Merge: 2b0be6c 0cde74f
Author: Michael Meeks <michael.meeks@collabora.com>
Date:   Tue Apr 28 11:41:31 2015 +0100

    Merge remote-tracking branch 'origin/feature/vclptr'
    
    Resolve several thousand lines of conflicts.
Comment 7 Michael Meeks 2015-05-06 20:00:57 UTC
Hi there; an interesting trace.

Caolan - is this expected ? - I imagine that the Combobox is re-sizing itself as it is destroyed (which is fun ;-) again, changes in which vtable gets used means that we now hit ComboBox::Resize in dispose rather than Window::Resize - which is interesting.

Anyhow - I've fixed ComboBox::Resize (just testing the patch), but I was wondering if this might help too:

0   libvcllo.dylib                	0x0000000103d0a1d9 ComboBox::Resize() + 185
1   libvcllo.dylib                	0x0000000103c74c10 vcl::Window::ImplCallResize() + 96
2   libvcllo.dylib                	0x0000000103ce9b58 vcl::Window::ImplPosSizeWindow(long, long, long, long, unsigned short) + 1944
3   libvcllo.dylib                	0x0000000103c35c50 ImplBorderWindow::Resize() + 384
4   libvcllo.dylib                	0x0000000103c3287e ImplSmallBorderWindowView::Init(OutputDevice*, long, long) + 1550
5   libvcllo.dylib                	0x0000000103c35c71 ImplBorderWindow::Resize() + 417
6   libvcllo.dylib                	0x0000000103ce33dc vcl::Window::remove_from_all_size_groups() + 92
7   libvcllo.dylib                	0x0000000103ce649d vcl::Window::dispose() + 2429
8   libvcllo.dylib                	0x0000000103d169c5 Edit::dispose() + 949
9   libvcllo.dylib                	0x0000000103d08723 ComboBox::dispose() + 323
10  libvcllo.dylib                	0x0000000103c44712 VclBuilder::disposeBuilder() + 82
11  libvcllo.dylib                	0x0000000103cc3335 TabPage::dispose() + 21
12  libsfxlo.dylib                	0x0000000102b8ab77 SfxTabDialog::RemoveTabPage(unsigned short) + 663
13  libpdffilterlo.dylib          	0x000000010d339ed5 ImpPDFTabDialog::dispose() + 21
14  libsvtlo.dylib                	0x00000001032f4ce3 svt::OGenericUnoDialog::destroyDialog() + 67
15  libpdffilterlo.dylib          	0x000000010d348f41 PDFDialog::executedDialog(short) + 321

--- a/vcl/source/window/window2.cxx
+++ b/vcl/source/window/window2.cxx
@@ -1443,7 +1443,7 @@ void Window::InvalidateSizeCache()
 
 void Window::queue_resize(StateChangedType eReason)
 {
-    if (IsDisposed())
+    if (IsDisposed() || mpWindowImpl->mbInDispose)
         return;
 
     bool bSomeoneCares = queue_ungrouped_resize(this);
-- 

But I'm no expert in the resize logic. Clearly we want to queue (but not do) a resize on the parent sizegroup or parent widget for later in the dispose case - since we know that the parent will in turn be shortly afterwards destroyed by the builder ;-) rather than doing that work.

Any thoughts ? =)
Comment 8 Michael Meeks 2015-05-07 08:36:30 UTC
fixed locally - will push in a sec.
Comment 9 Commit Notification 2015-05-07 08:39:16 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

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

tdf#90956 - ComboBox: handle re-size calculation during dispose.

It will be available in 5.0.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 10 Caolán McNamara 2015-05-07 09:37:23 UTC
I imagine that the problem is the explicit "Resize" (pBorderWindow->Resize()) on the border window due to bug 57090, the border windows stuff in vcl is sadly chaotic. Putting the mpWindowImpl->mbInDispose condition around that would presumably be safe seeing as the border window and the widget itself are sort of "the same thing" while sticking it at the top might hide that the widget has gone from containers and make them not reshuffle the remainder of their children
Comment 11 Commit Notification 2015-05-07 09:38:58 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#90956 don't resize the border window when disposing

It will be available in 5.0.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 12 Robinson Tryon (qubit) 2015-12-17 09:00:04 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]