Issue 87182 - Crash on formatting OLE Draw object
Summary: Crash on formatting OLE Draw object
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 2.4 RC6
Hardware: PC All
: P2 Normal with 2 votes (vote)
Target Milestone: AOO Later
Assignee: Armin Le Grand
QA Contact:
Keywords: crash, oooqa
Depends on:
Reported: 2008-03-18 09:43 UTC by jbf.faure
Modified: 2017-05-20 10:35 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

example file (14.55 KB, application/vnd.oasis.opendocument.text)
2008-03-18 09:44 UTC, jbf.faure
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description jbf.faure 2008-03-18 09:43:11 UTC
Steps to reproduce the crash :
- open odt joined file
- double click on embedded object
- select menu Format > Layer

verified under (K)ubuntu 6.06, MS-WinXP, MS-Vista with OOo 2.4 RC6 FR
Comment 1 jbf.faure 2008-03-18 09:44:27 UTC
Created attachment 52184 [details]
example file
Comment 2 jbf.faure 2008-03-18 09:49:05 UTC
crash report id : r82ju9 (for another test file).
I do not have yet the crash report id for the joined example file.
Comment 3 merschmann 2008-03-18 10:02:55 UTC
Can reproduce under WinXP Pro. 
Comment 4 cno 2008-03-18 10:02:56 UTC
Can reproduce the same bug in 2.3.1 on XP
2.2.1 on XP does not crash.
So it's ot a regression compared to 2.3.1
Comment 5 alex.thurgood 2008-03-18 11:40:35 UTC

Can't reproduce on :

NeoOffice 2.2.3 X11 Mac 2.4 m4 Aqua m243

So the regression happened somewhere between then and now ?

Comment 6 pierrepo 2008-03-18 12:40:46 UTC
Can reproduce with 2.3.0 on XP-SP2
Comment 7 andreschnabel 2008-04-30 12:59:47 UTC
I could see the crash with the attached example, but could not with a new file.

jbfaure: can you tell, how this file was created?
Comment 8 jbf.faure 2008-05-01 12:50:11 UTC
Hi Andre,

From the author of the file :
1st step : 
After having open Draw, insert, without modifying styles, the 2 objects that 
compose the drawing, the rhomb and the man head.
Save as odg file.

2nd step :
open Writer,
menu Insert > Object > OLE object ... > creating from a file and choose the 
odg file.
Save as odt file (non necessary in fact)

3rd step :
open the incorporated OLE object
select menu Format > Layer ... and crash

I have just reproduced this 3 steps. I will post the ID of crash report (OOo 
2.4.0) when I had received.
Comment 9 jbf.faure 2008-11-03 21:09:03 UTC
same crash with OOo 3.0 under Ubuntu 8.04
Comment 10 jbf.faure 2008-11-04 04:30:32 UTC
Crash report ID : r6k8uuc
Comment 11 jbf.faure 2009-08-12 07:26:15 UTC
Is it possible to define a target milestone for this bug ?

Crash report ID for OOo 3.1.1 RC1 under Ubuntu 8.04 : rxufqdc.

Kind regards
Comment 12 Armin Le Grand 2014-02-28 00:41:34 UTC
For some reason the sd::ViewShell does not create a LayerTabBar (it's missing in the activated OLE at the bottom). Despite that there are many accesses to DrawViewShell::GetLayerTabControl() which do not check the return value (which is empty in this case). Is there a reason no LayerTabBar is created in activated OLE mode? Need to check, else all places using it would need to be secured.
Comment 13 Armin Le Grand 2014-02-28 00:43:05 UTC
Interesting: There are places where internally mpLayerTabBar.get()!=NULL is checked.
Comment 14 Armin Le Grand 2014-02-28 01:13:17 UTC
The order of initialization seems to be different from normal application startup, the mpLayerTabBar member in GraphicViewShell is inited later as in application startup. It gets filled with the current layer in DrawViewShell::ChangeEditMode which has a switch bIsLayerModeActive that changes the local mbIsLayerModeActive. This should in my opinion only be switched to true (thats what happens and inits the LayerTabBar) when there is already one. When forcing not do do that as long as there is no LayerTabBar, the method DrawViewShell::ChangeEditMode gets called again (else not) with bIsLayerModeActive == true and now initializes it as expected. After that all works as in the Draw application.
Adding code to only switch mbIsLayerModeActive when there is a LayerTabBar (already checked in pLayerBar).
This will solve this problem. The value for bIsLayerModeActive is set from pView->IsLayerMode() in DrawViewShell::ReadFrameViewDatabut currently forced to true in GraphicViewShell::ChangeEditMode. If in the future the setting of pView->IsLayerMode() would be used again (what means Layers can be switched off) then all places accessing DrawViewShell::GetLayerTabControl() would have to be secured, too (29 places currently). Checking how hard that would be...
Comment 15 Armin Le Grand 2014-02-28 01:28:06 UTC
Not too hard, secured all accesses and asserted where useful. Checking changes...
Comment 16 Armin Le Grand 2014-02-28 02:09:31 UTC
Works as expected, preparing commit. Setting to normal, this might cause crashes when AOO Draw is used as OLE by other apps (outside AOO world), too.
Comment 17 SVN Robot 2014-02-28 02:15:29 UTC
"alg" committed SVN revision 1572807 into trunk:
i87182 secured usage of LayerTabBar in Draw application, ensured initializati...
Comment 18 Armin Le Grand 2014-02-28 02:17:37 UTC
Comitted, done.
Since it is a crash less, not unsafe to fix and may also crash when Draw is used as OLE from other apps I request 4.1.0 release blocker flag.
Comment 19 Armin Le Grand 2014-04-02 15:16:34 UTC
Not needed for release