Bug Hunting Session
Bug 58815 - [CRASH] new document, add slide/page, close without saving crashes Impress, Draw
Summary: [CRASH] new document, add slide/page, close without saving crashes Impress, Draw
Status: RESOLVED DUPLICATE of bug 55974
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta1
Hardware: Other All
: highest blocker
Assignee: Not Assigned
URL:
Whiteboard: bibisected40
Keywords: regression
: 59313 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-12-27 19:28 UTC by Jorendc
Modified: 2013-01-19 21:57 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Save this file as ppt (12.30 KB, application/vnd.oasis.opendocument.presentation)
2012-12-27 19:28 UTC, Jorendc
Details
Crash log Mac OS X 10.8.2 (165.99 KB, text/rtf)
2012-12-28 16:58 UTC, Jorendc
Details
stack trace. (15.15 KB, text/plain)
2013-01-11 12:48 UTC, Michael Meeks
Details
more debugging & valgrind log. (27.98 KB, text/plain)
2013-01-11 13:42 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jorendc 2012-12-27 19:28:02 UTC
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 1 Julien Nabet 2012-12-28 16:38:02 UTC
Comment on attachment 72198 [details]
Save this file as ppt

Fix mimetype
Comment 2 Julien Nabet 2012-12-28 16:44:30 UTC
On pc Debian x86-64 with 3.6 sources updated yesterday I don't reproduce this.

Joren: which LO version do you have?
Comment 3 Jorendc 2012-12-28 16:58:18 UTC
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.
Comment 4 Jorendc 2012-12-28 16:58:46 UTC
Created attachment 72223 [details]
Crash log Mac OS X 10.8.2
Comment 5 Jorendc 2012-12-28 17:03:28 UTC
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
Comment 6 Julien Nabet 2012-12-28 17:04:38 UTC
Joren: no problem :-) However I don't still reproduce this :-( Perhaps other will be "luckier" than me.
Comment 7 Marco Menardi 2012-12-28 17:45:16 UTC
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.
Comment 8 Jorendc 2012-12-28 17:51:32 UTC
(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
Comment 9 Jorendc 2012-12-28 20:09:32 UTC
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
Comment 10 Marco Menardi 2012-12-29 12:16:38 UTC
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
Comment 11 Jorendc 2012-12-29 14:53:15 UTC
(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.
Comment 12 ape 2013-01-04 11:17:11 UTC
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)
Comment 13 Julien Nabet 2013-01-04 11:36:15 UTC
ape: I put back former version, for more explanation, see https://wiki.documentfoundation.org/BugReport_Details#Version
Comment 14 Petr Mladek 2013-01-07 14:12:13 UTC
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.
Comment 15 ape 2013-01-07 15:21:51 UTC
(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'.
Comment 16 Michael Meeks 2013-01-11 11:53:28 UTC
The bug in comment #7 reproduces for me too - but not the steps in comment #1.
will take a look ...
Comment 17 Michael Meeks 2013-01-11 12:48:06 UTC
Created attachment 72854 [details]
stack trace.
Comment 18 Michael Meeks 2013-01-11 13:42:02 UTC
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.
Comment 19 Jorendc 2013-01-11 15:18:36 UTC
(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.
Comment 20 Michael Meeks 2013-01-11 17:01:58 UTC
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.
Comment 21 Michael Meeks 2013-01-11 17:08:51 UTC
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.
Comment 22 Jorendc 2013-01-13 14:47:31 UTC
*** Bug 59313 has been marked as a duplicate of this bug. ***
Comment 23 Michael Meeks 2013-01-14 09:29:58 UTC
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.
Comment 24 Caolán McNamara 2013-01-16 16:31:49 UTC

*** This bug has been marked as a duplicate of bug 55974 ***
Comment 25 Jorendc 2013-01-19 21:57:23 UTC
*** Bug 59590 has been marked as a duplicate of this bug. ***