Issue 93818

Created attachment 56470 [details]
This test document crashes writer by adding note and printing

Related to this bug, the crash reporting IDs, generated by the OpenOffice.org
error report tool, are: rkknyuc and rvknyuc

Reassigned to HI.

Could not reproduce, but the report ID's should help to find whats going on.

I could reproduce this error/crashes several times using Openoffice 3.0 release
candidate2.

Here are the error report numbers: rkfhyuc r2fhyuc rwfhyuc

Isn't this a release critical issue? If I could find this error playing a few
minutes with the release candidate, probably others will have the same problem
as well?!

those stacktraces seem to indicate that an EditEngine is doing something with a
dead or broken MetaFile. tl: any input on this ?

TL: I don't have any problem at all with loading this document in OOo 300m7
(which I was told is RC2). Also it does not crash in a OOo 300m3 based CWS...

Thus since this seems to be stack-trace-guessing-only I leave the current target
and look into this again at some later point.

@TL: I tried to narrow the problem down a little bit. Following steps had a 100%
crash guarantee on three different computers. All were running WindowsXP
(german) with OpenOffice.org 3.0 rc2 (german):

1. Please open the attachment test.doc with writer
2. Add a note/comment somewhere in the text.
3. Print the document.
4. Print the document a second time, but not using the same printer. Choose
another printer for printing.
5. OOo crashes.

I hope you can reproduce my crashes...

@TL: I don't want to bother you with error reports, but during my tests on
different computers (please see my last comment), the error report tool sent me
some report IDs: 
rp55yuc , r755yuc , rs55yuc, rx55yuc , rum5yu , rvm5yuc , rdm5yuc 

Thank you
Gerald

It seems the report tool is out of business today. :-( 
Will check again tomorrow...

The stack traces look like this:

tlmi!Container::Insert+0x7 [o:\ooo300\src.m7\tools\source\memtools\contnr.cxx @ 864]
vclmi!GDIMetaFile::AddAction+0x20 [o:\ooo300\src.m7\vcl\source\gdi\gdimtf.cxx @ 626]
vclmi!OutputDevice::Push+0x42 [o:\ooo300\src.m7\vcl\source\gdi\outdev.cxx @ 2674]
svxmi!ImpEditEngine::CalcLineWidth+0x34
[o:\ooo300\src.m7\svx\source\editeng\impedit2.cxx @ 3082]
svxmi!ImpEditEngine::CalcTextWidth+0xfd
[o:\ooo300\src.m7\svx\source\editeng\impedit2.cxx @ 3059]
svxmi!EditEngine::CalcTextWidth+0x29
[o:\ooo300\src.m7\svx\source\editeng\editeng.cxx @ 1283]
svxmi!Outliner::CalcTextSize+0x19
[o:\ooo300\src.m7\svx\source\outliner\outlin2.cxx @ 324]
swmi!SwPostIt::GetPostItTextHeight+0x1d
[o:\ooo300\src.m7\sw\source\ui\docvw\postit.cxx @ 1268]
swmi!SwPostItMgr::LayoutPostIts+0x297
[o:\ooo300\src.m7\sw\source\ui\docvw\postitmgr.cxx @ 596]
swmi!SwView::OuterResizePixel+0x3a4
[o:\ooo300\src.m7\sw\source\ui\uiview\viewport.cxx @ 1264]
sfxmi!SfxViewFrame::DoAdjustPosSizePixel+0x3a
[o:\ooo300\src.m7\sfx2\source\view\viewfrm.cxx @ 1936]
sfxmi!SfxViewFrame::InvalidateBorderImpl+0xd1
[o:\ooo300\src.m7\sfx2\source\view\viewfrm.cxx @ 1477]
sfxmi!SfxViewShell::InvalidateBorder+0xc
[o:\ooo300\src.m7\sfx2\source\view\viewsh.cxx @ 1031]
swmi!SwView::CreateVLineal+0x6d
[o:\ooo300\src.m7\sw\source\ui\uiview\viewmdi.cxx @ 619]
swmi!lcl_SetUIPrefs+0xce [o:\ooo300\src.m7\sw\source\ui\app\swmodul1.cxx @ 130]
swmi!SwModule::ApplyUsrPref+0x1d5
[o:\ooo300\src.m7\sw\source\ui\app\swmodul1.cxx @ 249]
swmi!SwView::DoPrint+0x439 [o:\ooo300\src.m7\sw\source\ui\uiview\viewprt.cxx @ 295]
sfxmi!SfxViewShell::ExecPrint_Impl+0x17bc
[o:\ooo300\src.m7\sfx2\source\view\viewprn.cxx @ 776]
sfxmi!SfxStubSfxViewShellExecPrint_Impl+0xe
[o:\ooo300\src.m7\sfx2\wntmsci12.pro\inc\sfxslots.hxx @ 817]
sfxmi!SfxShell::ExecuteSlot+0xc1 [o:\ooo300\src.m7\sfx2\source\control\shell.cxx
@ 964]
swmi!SwView::ExecutePrint+0x3ca
[o:\ooo300\src.m7\sw\source\ui\uiview\viewprt.cxx @ 555]
swmi!SfxStubSwViewExecutePrint+0xe
[o:\ooo300\src.m7\sw\wntmsci12.pro\inc\swslots.hxx @ 11247]
sfxmi!SfxDispatcher::Call_Impl+0x3ff
[o:\ooo300\src.m7\sfx2\source\control\dispatch.cxx @ 306]
sfxmi!SfxDispatcher::PostMsgHandler+0xdf
[o:\ooo300\src.m7\sfx2\source\control\dispatch.cxx @ 1619]
sfxmi!SfxDispatcher::LinkStubPostMsgHandler+0xe
[o:\ooo300\src.m7\sfx2\source\control\dispatch.cxx @ 1579]
tlmi!Link::Call+0x11 [o:\ooo300\src.m7\tools\inc\tools\link.hxx @ 142]
sfxmi!SfxHintPoster::DoEvent_Impl+0xe
[o:\ooo300\src.m7\sfx2\source\notify\hintpost.cxx @ 84]
sfxmi!SfxHintPoster::LinkStubDoEvent_Impl+0xe
[o:\ooo300\src.m7\sfx2\source\notify\hintpost.cxx @ 87]
tlmi!Link::Call+0x11 [o:\ooo300\src.m7\tools\inc\tools\link.hxx @ 142]
vclmi!ImplHandleUserEvent+0x46 [o:\ooo300\src.m7\vcl\source\window\winproc.cxx @
1999]
vclmi!ImplWindowFrameProc+0x2cc [o:\ooo300\src.m7\vcl\source\window\winproc.cxx
@ 2499]
vclmi!SalFrame::CallCallback+0x16 [o:\ooo300\src.m7\vcl\inc\vcl\salframe.hxx @ 286]
vclmi!ImplHandleUserEvent+0x24
[o:\ooo300\src.m7\vcl\win\source\window\salframe.cxx @ 4503]
vclmi!SalFrameWndProc+0x714 [o:\ooo300\src.m7\vcl\win\source\window\salframe.cxx
@ 6047]
vclmi!SalFrameWndProcW+0x30 [o:\ooo300\src.m7\vcl\win\source\window\salframe.cxx
@ 6204]

issue confirmed in OO.o 3 final release

We're seeing the same thing there (it happens on both Solaris and Linux).   The
one point I'd add this that it seems to be more related to using a non-default
printer than printing twice.  In other words, all that is needed is to open the
document (with notes), select print, and pick a non-default printer.

It also crashes when "Print to File" is checked, so that can be used to save
some paper during testing

Not time left to fix  this one in OO0 3.1 because of other issues.

*** Issue 98890 has been marked as a duplicate of this issue. ***

TL->PL: What causes the problem in GDIMetaFile::AddAction is an access
violation. Probably since the this pointer was 0xffffffff. 
But already when ImpEditEngine::CalcLineWidth is reached for the first time then
the reference device does already contain broken/uninitialized pointers to
mpNextGraphics and mpMetaFile.
Can you have a look at this? Thanks!

This crash seems to be easy to hit.

Philipp,
are we on track for 3.2 with fix for this crasher?

kpalagin: why do you ask ?

cannot reproduce in DEV300m50, neither windows nor mac. Perhaps I'm to stupid again.

@hi: can you reproduce this ?

I'm able to reproduce it (also with Dev300m50) with the second description from
reporter.
See the comment from "gleppert Fri Sep 26 08:44:10 +0000 2008" 

ok, that second scenario explains why the output device in question is dead
already. It means the edit engine works one some previously set pointer to the
now dead first printer, right ? Perhaps it makes sense to see this in the CWS
printerpullpages scenario, since the printing goes other paths now ?

tl: no findings in CWS printerpullpages when printing with "notes at end of each
page". Unfortunately that CWS is now set to OOo 3.3.

Added this task to that CWS.

Fixed in CWS printerpullpages.

tl->gleppert: you may want to try the next public available build of the CWS
printerpullpages when it becomes available.

.

please verify in CWS printerpullpages

Verified with cws printerpullpages = OK

Nah, I know what the problem is here.

Take a .odt with notes in it and that has compatibility options "on" to use
printer metrics. Load it up. file->print, change the printer. Doomage looms
after this on the next time that a note has to be redrawn to screen.

See sw/source/ui/docvw/postit.cxx SwMarginWin::InitControls there we have...

OutputDevice* pDev = aShell->GetDoc()->getReferenceDevice(TRUE);
if ( pDev )
{
  mpOutliner->SetRefDevice( pDev );
}

because the document is using printer metrics this getReferenceDevice returns
the original printer OutputDevice from SwDoc::getPrinter. When we change the
printer from the print dialog that calls SwDoc::setPrinter and deletes that old
OutputDevice so the postit outliner is now left using a deleted OutputDevice.

Presumably when we're not using printer metrics and using the virtual device the
possibility of a SwDoc::setVirtualDevice being called that deletes the old
virtual device is sufficiently rare that, with this being the default for new
documents, its rare or impossible to delete the outputdevice from out under the
postit outliner in that mode.

So the question is, why do we bother setting a Reference device for the notes
outliner ? The default one from the svx pool would presumably be fine and should
always exist and not get destroyed before the outliner does. We're only drawing
to the margin window on screen so we don't need to follow any specific printer
metrics to achieve that, right ? and makes things safer and easier.

cmc->mba: This is a postit issue in sw. I think you were last looking after that
stuff

Created attachment 69158 [details]
why not just do this

I was young, needed the money and probably did some copy/paste action without
knowing what I was doing

If notes still work without that code, definitly the right thing to do

good catch: SwPostItMgr using a dead OutputDevice has resulted in about 2000 crash reports...

I'm not sure if this is the same bug as the reported one; but anyway it needs to
be fixed.

First I would like to check why the reference device was set here. Similar code
is found in e.g. source/core/doc/docdraw.cxx, but with "false" as parameter. But
there are more places in the Writer code where this construct is used. I would
like to understand why this leads to a crash here but obviously not elsewhere.

BTW: This concept of a reference device looks completely broken to me as it
doesn't use refcounting or notifications.

re: "I would like to understand why this leads to a crash here but obviously not
elsewhere.", probably (I didn't pursue it further) because when the printer gets
changed, SwDoc::PrtDataChanged gets called which updates the draw models device
with pDrawModel->SetRefDevice etc.

And I'm convinced that this is the trigger for the original report (that .doc
has use printer metrics set on as extra evidence). And the stack tl posted
matches the stack from valgrind with my example scenario.

Sounds reasonable.

I also think that you are right about the RefDevice not being necessary at all.
So I will apply your patch to a CWS I have open already.

Thanks.

fixed in cws mba33issues01

please verify in CWS mba33issues01

Verified with cws mba33issues01 = ok

*** Issue 110185 has been marked as a duplicate of this issue. ***

*** Issue 94542 has been marked as a duplicate of this issue. ***