Created attachment 72198 [details] Save this file as ppt How to reproduce: Download attached document, or follow this steps: * Create new presentation * Delete header of first slide * Enter some text in the textbox (Click to add text) * Create an empty slide * Save this presentation as .ppt * Crash (if not, close window (click on the 'x') -> crash)
Comment on attachment 72198 [details] Save this file as ppt Fix mimetype
On pc Debian x86-64 with 3.6 sources updated yesterday I don't reproduce this. Joren: which LO version do you have?
Oh, I'm sorry. Damn, I made a bad bug report :s. I'm sorry for that. My bad. Ok, here some additional info: I tried again to reproduce this bug using my attached file, but I can't reproduce it using that file. I still CAN reproducing following the 'how to reproduce' steps. Mac OS X 10.8.2 LibreOffice 4.1.0.0.alpha0+ (Build ID: 699132c269a6c6d9e815fc582e2e6a106e46923) TinderBox: MacOSX-Intel@1-built_no-moz_on_10.6.8, Branch:master, Time: 2012-12-27_01:05:51 I'll upload crash log.
Created attachment 72223 [details] Crash log Mac OS X 10.8.2
Reproducible also with 4.0.0.0.beta1+ (Build ID: f4a1520c58f8bbbaf5027222c071374afb55961) TinderBox: MacOSX-Intel@27-OSX_10.7.0-gcc_4.2.1_llvm, Branch:libreoffice-4-0, Time: 2012-12-16_21:58:26 CAN'T reproduce using Version 3.6.4.3 (Build ID: 2ef5aff) So -> REGRESSION
Joren: no problem :-) However I don't still reproduce this :-( Perhaps other will be "luckier" than me.
Libo 4.0beta2, Debian GNU/Linux 64 I can reproduce and even in a simple manner: - Impress 4.0beta2, File -> New -> Create button - go to the left panel, right click, "New slide" - File -> Close, when asked click "Close without saving" - Impress crashes! If you start it again, it asks for recovery. With 3.6.2 works fine.
(In reply to comment #7) > Libo 4.0beta2, Debian GNU/Linux 64 > I can reproduce and even in a simple manner: > - Impress 4.0beta2, File -> New -> Create button > - go to the left panel, right click, "New slide" > - File -> Close, when asked click "Close without saving" > - Impress crashes! > If you start it again, it asks for recovery. > With 3.6.2 works fine. I can confirm that; Works fine with 3.6.4.3 Crashes with LO 4.0 beta 1, beta 2 and 4.1 master Following https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg -> Priority 'Critical' and 'Highest'. Added to mab4.0
git bisect log: git bisect start # skip: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect skip 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect good 65fd30f5cb4cdd37995a33420ed8273c0a29bf00 # bad: [5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a] source-hash-8450a99c744e9005f19173e4df35d65640bcf5c4 git bisect bad 5b4b36d87517a6ea96ff8c84c46b12f462fc9a1a # good: [16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9] source-hash-099198a4224778fe6e43f5dc13b5b9b1b4dc828c git bisect good 16b0b88cbd4ef0f51816e97277e40c5cf78f7bf9 # good: [f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a] source-hash-a581d31b227623e09d2970a91214fda398f98eda git bisect good f28b8f9a6c47fa59bf98fffe937a2f2db7a2445a # bad: [114fd3b76bcba890e6d702d00cef910f1493c262] source-hash-64ab96cd15e52da88781e720d6f031dbcd0ba902 git bisect bad 114fd3b76bcba890e6d702d00cef910f1493c262 # good: [6af64581913aa7ce3fcf0890fe671830d416a6ea] source-hash-06a8ca9339f02fccf6961c0de77c49673823b35f git bisect good 6af64581913aa7ce3fcf0890fe671830d416a6ea # good: [7e20e241c1d8819d8d5edb7894baeddde33f9d3a] source-hash-2c270eeff422ef93100376ce0717a131d4f3cc2f git bisect good 7e20e241c1d8819d8d5edb7894baeddde33f9d3a # good: [62b2ae5ee4cc77ad0b399c5a716ef526023d13ab] source-hash-e9960f36675a025c0536dec30ae56c50f4adecb1 git bisect good 62b2ae5ee4cc77ad0b399c5a716ef526023d13ab # bad: [e7627bbadeb1ab2ff16757dd240d55c0023f8257] source-hash-5b195fbcf7a441aeb193f6abd08b877e580938e0 git bisect bad e7627bbadeb1ab2ff16757dd240d55c0023f8257 # good: [6f5853805cc557b8dd50ed2d76fc8ec917544575] source-hash-7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d git bisect good 6f5853805cc557b8dd50ed2d76fc8ec917544575
I've to add that crashes Drawing too! Reproduce: same as Impress. Open Drawing, on the left panel right click, New Page, close the document, click NO save, Drawing crashes
(In reply to comment #10) > I've to add that crashes Drawing too! > Reproduce: same as Impress. > Open Drawing, on the left panel right click, New Page, close the document, > click NO save, Drawing crashes I can reproduce that.
LOdev_4.1 crashes when closing a new empty (ODG or ODP) document: WindowsXP 64-bit; LOdev_4.1.0.0.alpha0+ (ID: 6a393297ce6d99bbc4edefbf01ab9c5c6f0eff8; TinderBox: Win-x86@6, Branch:master, Time: 2013-01-04_01:06:01). 1. Run Draw or Impress 2. Close the new empty document (i.e., close the Draw or Impress) 3. LOdev_4.1.0.0.alpha0+ suffers crash. But LOdev_4.0.0.0.beta2+ - OK. These are regressions compared to LOdev_4.0.0.0.beta2 (ID assembly: b060b43f093dce23222fd99375b1c6bd433703d; Tinderbox <l.lunak@suse.cz>: Win-x86 @ 6, time 2013-01-03 13:16:15)
ape: I put back former version, for more explanation, see https://wiki.documentfoundation.org/BugReport_Details#Version
I have reproduced the steps from the comment #7 on Linux as well. I used my own build from libreoffice-4-0 branch, pulled today morning.
(In reply to comment #14) > I have reproduced the steps from the comment #7 on Linux as well. I used my > own build from libreoffice-4-0 branch, pulled today morning. 1. Switch Off left panel: View > Slide Panel (Impress) \ Page Pane (Draw) 2. Agree with the restoration of "Untitled_1.odp \ odg". 3. Starts smath.exe (Windows OS only) and closes its after. -- Impress and Draw are working right. 'Add Slide(impress)\Page(Draw)' option works too across 'Insert > Slide'.
The bug in comment #7 reproduces for me too - but not the steps in comment #1. will take a look ...
Created attachment 72854 [details] stack trace.
Created attachment 72855 [details] more debugging & valgrind log. I get some deja-vu with this; IIRC I've seen a duplicate of it in the past. It strongly looks like yet-another artifact of VCL's lack of reference-counting.
(In reply to comment #16) > The bug in comment #7 reproduces for me too - but not the steps in comment > #1. > will take a look ... I can't confirm it anymore with my own steps either (Description); But I can indeed still reproduce with comment #7.
Wonderful; as expected it is basically VCL being unutterably horrible lifecycle wise: --- a/toolkit/source/awt/vclxdevice.cxx +++ b/toolkit/source/awt/vclxdevice.cxx @@ -53,6 +53,8 @@ VCLXDevice::~VCLXDevice() void VCLXDevice::DestroyOutputDevice() { + fprintf (stderr, "Destroy output device %p: '%s'\n", + mpOutputDevice, mpOutputDevice ? typeid(*mpOutputDevice).name() : "<null>"); delete mpOutputDevice; mpOutputDevice = NULL; } prints out: Destroy output device 0x8955ee0: 'N2sd6WindowE' Destroy output device 0x8956268: '9ScrollBar' Destroy output device 0x8956d30: '9ScrollBar' Destroy output device 0x8957060: '12ScrollBarBox' I get: #0 std::list<Link, std::allocator<Link> >::remove (this=0x50, __value=...) at /data/opt/libreoffice/libreoffice-4-0/vcl/source/app/vclevent.cxx:162 #1 0xb67f9533 in VclEventListeners::removeListener (this=0x50, rListener=...) at /data/opt/libreoffice/libreoffice-4-0/vcl/source/app/vclevent.cxx:110 #2 0xb6a04fed in Window::RemoveEventListener (this=0x8955ee0, rEventListener=...) at /data/opt/libreoffice/libreoffice-4-0/vcl/source/window/window.cxx:5310 #3 0xacb17099 in sd::slidesorter::SlideSorter::ReleaseListeners (this=0x89584c8) at /data/opt/libreoffice/libreoffice-4-0/sd/source/ui/slidesorter/shell/SlideSorter.cxx:403 #4 0xacb17649 in sd::slidesorter::SlideSorter::~SlideSorter (this=0x89584c8, __in_chrg=<optimized out>) at /data/opt/libreoffice/libreoffice-4-0/sd/source/ui/slidesorter/shell/SlideSorter.cxx:218 #5 0xacb17862 in sd::slidesorter::SlideSorter::~SlideSorter (this=0x89584c8, __in_chrg=<optimized out>) at /data/opt/libreoffice/libreoffice-4-0/sd/source/ui/slidesorter/shell/SlideSorter.cxx:246 The slide-sorter has this rather naive / optimistic boost::shared_ptr: typedef ::boost::shared_ptr<sd::Window> SharedSdWindow; ... class SlideSorter : private ::boost::noncopyable { ... SharedSdWindow mpContentWindow; Which is just hard deleted by a toolkit peer: ==24244== Address 0xe2a2484 is 244 bytes inside a block of size 324 free'd ==24244== at 0x4027F33: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==24244== by 0x4FC1085: VCLXDevice::DestroyOutputDevice() (vclxdevice.cxx:56) ==24244== by 0x4FE34F1: VCLXWindow::dispose() (vclxwindow.cxx:957) ==24244== by 0x509F5B6: UnoWrapper::WindowDestroyed(Window*) (unowrapper.cxx:263) ==24244== by 0x56BE2B4: Window::~Window() (window.cxx:4333) ==24244== by 0x56936B6: SystemWindow::~SystemWindow() (syswin.cxx:85) ==24244== by 0x56C5C77: WorkWindow::~WorkWindow() (wrkwin.cxx:142) ==24244== by 0x56C5CB1: WorkWindow::~WorkWindow() (wrkwin.cxx:150) ==24244== by 0x12A6BD70: boost::detail::sp_counted_impl_p<WorkWindow>::dispose() (checked_delete.hpp:34) ==24244== by 0x12991C0F: boost::detail::shared_count::~shared_count() (sp_counted_base_gcc_x86.hpp:145) ==24244== by 0x12A69E5E: sd::framework::BasicViewFactory::~BasicViewFactory() (shared_ptr.hpp:168) ==24244== by 0x12A69F1F: sd::framework::BasicViewFactory::~BasicViewFactory() (BasicViewFactory.cxx:145) Which is just silly. Quite why toolkit thinks it can go deleting windows like that - I have no idea. The ownership of those resources is extraordinarily unclear.
Digging at the bibsect: git log 7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d..5b195fbcf7a441aeb193f6abd08b877e580938e0 -- sd/ suggest that Thorsten's commit: commit aa1927dc257b52edf96de220cc3797e02c83a0ae Author: Thorsten Behrens <tbehrens@suse.com> Date: Wed Oct 10 10:57:35 2012 +0200 Make svg export use slidesorter selection in most cases. There was code previously that took the current selection, iff Impress main view was in slidesorter mode. Extended this quite helpful functionality to also work in other modes (as long as a slidesorter pane is displayed & has up-to-date selection, it should work). Change-Id: Ibbfe630a4ca31aa52978501745c2eef0d79fb8e3 91 0 sd/source/ui/framework/factories/ViewShellWrapper.cxx 13 2 sd/source/ui/inc/framework/ViewShellWrapper.hxx Is almost certainly to blame for changing the ordering in subtle ways here: + ::boost::shared_ptr< ::sd::slidesorter::SlideSorterViewShell > mpSlideSorterViewShell; ... @@ -64,6 +75,8 @@ ViewShellWrapper::ViewShellWrapper ( const Reference<awt::XWindow>& rxWindow) : ViewShellWrapperInterfaceBase(MutexOwner::maMutex), mpViewShell(pViewShell), + mpSlideSorterViewShell( + ::boost::dynamic_pointer_cast< ::sd::slidesorter::SlideSorterViewShell >( pViewShell )), mxViewId(rxViewId), mxWindow(rxWindow) { in particular.
*** Bug 59313 has been marked as a duplicate of this bug. ***
So the solution to this is either/and: * add functionality to toolkit/ to tag that some UNO peers don't own the underly outputdevice / widget: seems like a useful feature anyway. The snag is that we need to work out who is creating the VCLXDevice for that widget. * add some null-able smart pointer that goes NULL when it gets destroyed for the sd::Window class (or even vcl::OutputDevice ?), such that we can detect and handle this case sanely. I'll try to poke at either/both of those in my spare cycles.
*** This bug has been marked as a duplicate of bug 55974 ***
*** Bug 59590 has been marked as a duplicate of this bug. ***