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.
Created attachment 115208 [details] LO crashlog
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.
Hmm, your test was on a more recent version than mine, let me restest again
Confirmed on daily from 30/04/2015 ===> regression
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
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.
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 ? =)
fixed locally - will push in a sec.
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.
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
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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]