Issue 93818 - Writer crashes printing this document with note
Summary: Writer crashes printing this document with note
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: printing (show other issues)
Version: OOo 3.0
Hardware: All Windows XP
: P2 Trivial (vote)
Target Milestone: ---
Assignee: h.ilter
QA Contact: issues@sw
URL:
Keywords:
: 94542 98890 110185 (view as issue list)
Depends on:
Blocks:
 
Reported: 2008-09-12 11:56 UTC by gleppert
Modified: 2017-05-20 11:41 UTC (History)
9 users (show)

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


Attachments
This test document crashes writer by adding note and printing (66.50 KB, application/msword)
2008-09-12 11:57 UTC, gleppert
no flags Details
why not just do this (549 bytes, patch)
2010-04-28 11:50 UTC, caolanm
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description gleppert 2008-09-12 11:56:48 UTC
I just downloaded and tested Openoffice 3.0 Release candidate 1 and had a
reproducible crash using Writer.

How to crash writer?

1. Please open the attachment to this issue with writer
2. Add a note somewhere in the text
3. Try to print the recent page.

This results in an immediate crash of OpenOffice.
Comment 1 gleppert 2008-09-12 11:57:57 UTC
Created attachment 56470 [details]
This test document crashes writer by adding note and printing
Comment 2 gleppert 2008-09-12 12:32:16 UTC
Related to this bug, the crash reporting IDs, generated by the OpenOffice.org
error report tool, are: rkknyuc and rvknyuc
Comment 3 michael.ruess 2008-09-12 13:45:06 UTC
Reassigned to HI.
Comment 4 h.ilter 2008-09-15 11:50:18 UTC
Could not reproduce, but the report ID's should help to find whats going on.
Comment 5 gleppert 2008-09-22 22:20:00 UTC
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?!
Comment 6 philipp.lohmann 2008-09-23 09:52:46 UTC
those stacktraces seem to indicate that an EditEngine is doing something with a
dead or broken MetaFile. tl: any input on this ?
Comment 7 thomas.lange 2008-09-23 10:08:52 UTC
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.
Comment 8 gleppert 2008-09-26 09:44:10 UTC
@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...

Comment 9 gleppert 2008-09-26 18:44:15 UTC
@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
Comment 10 thomas.lange 2008-09-29 11:26:22 UTC
It seems the report tool is out of business today. :-( 
Will check again tomorrow...
Comment 11 thomas.lange 2008-09-29 14:42:21 UTC
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]

Comment 12 gleppert 2008-10-17 12:44:02 UTC
issue confirmed in OO.o 3 final release
Comment 13 psfales 2008-10-29 21:22:41 UTC
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
Comment 14 thomas.lange 2009-01-19 14:42:48 UTC
Not time left to fix  this one in OO0 3.1 because of other issues.
Comment 15 michael.ruess 2009-02-04 21:30:23 UTC
*** Issue 98890 has been marked as a duplicate of this issue. ***
Comment 16 thomas.lange 2009-04-22 14:01:25 UTC
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!
Comment 17 kpalagin 2009-05-29 13:46:14 UTC
This crash seems to be easy to hit.

Philipp,
are we on track for 3.2 with fix for this crasher?
Comment 18 philipp.lohmann 2009-05-29 14:38:12 UTC
kpalagin: why do you ask ?
Comment 19 philipp.lohmann 2009-06-23 15:29:27 UTC
cannot reproduce in DEV300m50, neither windows nor mac. Perhaps I'm to stupid again.

@hi: can you reproduce this ?
Comment 20 h.ilter 2009-06-24 10:52:31 UTC
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" 
Comment 21 philipp.lohmann 2009-06-24 14:02:46 UTC
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 ?
Comment 22 thomas.lange 2009-09-10 12:53:51 UTC
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.
Comment 23 thomas.lange 2009-09-10 12:55:20 UTC
tl->gleppert: you may want to try the next public available build of the CWS
printerpullpages when it becomes available.
Comment 24 thomas.lange 2009-09-10 12:58:45 UTC
.
Comment 25 philipp.lohmann 2009-10-26 13:48:32 UTC
please verify in CWS printerpullpages
Comment 26 h.ilter 2009-11-11 13:24:28 UTC
Verified with cws printerpullpages = OK
Comment 27 caolanm 2010-04-28 11:48:50 UTC
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.
Comment 28 caolanm 2010-04-28 11:49:31 UTC
cmc->mba: This is a postit issue in sw. I think you were last looking after that
stuff
Comment 29 caolanm 2010-04-28 11:50:13 UTC
Created attachment 69158 [details]
why not just do this
Comment 30 max.odendahl 2010-04-28 12:26:27 UTC
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
Comment 31 hdu@apache.org 2010-04-28 13:49:11 UTC
good catch: SwPostItMgr using a dead OutputDevice has resulted in about 2000 crash reports...
Comment 32 Mathias_Bauer 2010-04-28 14:15:57 UTC
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.
Comment 33 caolanm 2010-04-28 14:29:24 UTC
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.
Comment 34 Mathias_Bauer 2010-04-28 15:40:41 UTC
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.
Comment 35 Mathias_Bauer 2010-05-10 12:45:24 UTC
fixed in cws mba33issues01
Comment 36 Mathias_Bauer 2010-06-03 11:04:02 UTC
please verify in CWS mba33issues01
Comment 37 h.ilter 2010-06-07 11:18:16 UTC
Verified with cws mba33issues01 = ok
Comment 38 max.odendahl 2010-06-21 10:12:06 UTC
*** Issue 110185 has been marked as a duplicate of this issue. ***
Comment 39 hdu@apache.org 2010-07-29 10:12:24 UTC
*** Issue 94542 has been marked as a duplicate of this issue. ***