Issue 106390 - Crash when closing stylist via closer
Summary: Crash when closing stylist via closer
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: OOO320m2
Hardware: All Linux, all
: P2 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords: regression
Depends on:
Blocks: 99999
  Show dependency tree
 
Reported: 2009-10-28 16:44 UTC by wolframgarten
Modified: 2017-05-20 10:29 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description wolframgarten 2009-10-28 16:44:24 UTC
Open a new impress, hit F11, right click on background objects, choose modify,
close the dialog via the closer and the stylist, too: Office crashes.
Comment 1 wolframgarten 2009-10-28 16:45:26 UTC
Keyword set.
Comment 2 clippka 2009-10-29 14:09:47 UTC
we crash in SfxDispatcher::PostMsgHandler and only if sfx2 is not compiled with
debug information :-(

Valgrind shows an illegal 4 byte read in PostMsgHandler but I suspect we have a
corruption inside the "Call_Impl( *pSh, *pSlot, *pReq, pReq->AllowsRecording() );"
line which should close the stylist.

The slot in question is SID_STYLE_DESIGNER.

I'm out of ideas currently I will try to remove my recent changes to the
template dialog to see if they are the root cause...
Comment 3 clippka 2009-10-29 15:32:53 UTC
the revert of issue 23221 didn't change anything, still crashes.

It only crashes in impress and only if one of the presentation styles is
selected, context menu modify is selectend and then either ok, cancel or closer
is pressed.

Since debuging does not help here and I'm out of ideas I will start to review
the code..
Comment 4 clippka 2009-10-29 15:58:07 UTC
interesting, if I disable the creation of the dialog to edit the style in
FuTemplate::DoExecute, the crash still happens. I think I can rule out that
dialog as the source of this problem...
Comment 5 clippka 2009-10-29 16:23:20 UTC
if I make FuTemplate::DoExecute a noop, it still crashes. This gets even more
interesting...
Comment 6 clippka 2009-10-30 12:11:12 UTC
Just return in the slots exec method FuTemporary does still crash. So the issue
is unlikely to be in sd module, at least not during slot execution.

I tried a non pro build dev300m63 but like building sfx2 with debug this also
does not crash and does not give any assertions (which I hoped for).

I will investigate further what happens in sfx2 after the slot is called. Maybe
an issue with updating the slot state? Compiler bug since this is a linux only
issue? I'm running out of ideas fast...
Comment 7 clippka 2009-10-30 13:26:53 UTC
the crash does not happen if I build all obj files in sfx2/source/app without
optimization. This looks more and more like a compiler error. I will try to
pinpoint which obj file fails...
Comment 8 clippka 2009-10-30 15:48:26 UTC
in sfx2/source/control/makefile.mk, there already is this code

# w.g. compilerbugs
.IF "$(GUI)"=="WNT"
.IF "$(COM)"!="GCC"
CFLAGS+=-Od
.ENDIF
.ENDIF

If a append

+.IF "$(COM)"=="GCC"
+CFLAGS+=-O0
+.ENDIF

then the crash does not happen anymore.

cl->mba: I don't like to do such changes to modules I do not own so please take
over or dispatch
Comment 9 Mathias_Bauer 2009-11-19 16:58:30 UTC
I will have to do a lot of research to find out if this is a real bug that
switching off optimization just fixes by accident.
So for the time being I take your fix. We have planned to check "noopt" compiles
anyway, so we can postpone that now.
Comment 10 mikhail.voytenko 2009-11-24 16:06:31 UTC
mav->wg: Please verify the issue.
Comment 11 wolframgarten 2009-12-03 10:55:31 UTC
Verified in CWS.