Created attachment 52184 [details]
example file

crash report id : r82ju9 (for another test file).
I do not have yet the crash report id for the joined example file.

Can reproduce under WinXP Pro. 

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

Hi,

Can't reproduce on :

NeoOffice 2.2.3
OpenOffice.org X11 Mac 2.4 m4
OpenOffice.org Aqua m243

So the regression happened somewhere between then and now ?

Alex

Can reproduce with 2.3.0 on XP-SP2

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?

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.

same crash with OOo 3.0 under Ubuntu 8.04

Crash report ID : r6k8uuc

Hi,
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
JBF

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.

Interesting: There are places where internally mpLayerTabBar.get()!=NULL is checked.

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...

Not too hard, secured all accesses and asserted where useful. Checking changes...

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.

"alg" committed SVN revision 1572807 into trunk:
i87182 secured usage of LayerTabBar in Draw application, ensured initializati...

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.

Not needed for release