Issue 102380 - Impress hangs when opening a big file
Summary: Impress hangs when opening a big file
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1
Hardware: All All
: P2 Trivial (vote)
Target Milestone: OOo 3.1.1
Assignee: wolframgarten
QA Contact: issues@graphics
Keywords: crash, regression
: 102627 (view as issue list)
Depends on:
Reported: 2009-05-30 11:51 UTC by nexonic
Modified: 2009-07-30 11:33 UTC (History)
5 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description nexonic 2009-05-30 11:51:22 UTC
When I open a big file in 3.1 Impress, it hangs/crashes.
The file I'm using has got a size of 257 MB and 202 slides. Each slide contains
an imported image of approximately 1.5 MB. 
The issue occures on Linux as well as on Windows. That is my hardware:
* AMD Athlon 64 LE-1640 2.6 GHz
* 2 GB RAM
* 256 MB shared memory graphic

1. I opened the file by a double-click
2. OpenOffice started loading the file after the progress bar on the bottom finished
3. After a while I couldn't move the cursor anymore and I had to reboot the computer

In versions less than 3.1 everything works well.
Comment 1 kpalagin 2009-05-30 20:49:47 UTC
is there a way you can provide the file?
Comment 2 nexonic 2009-05-30 22:12:51 UTC
I couldn't find a hoster that allows such a big file so I had to upload it on my

Unfortunately I can't keep the server running everytime.
Comment 3 kpalagin 2009-05-31 14:28:45 UTC
Confirming with 3.1 on WinXP. Repro:
1. Open linked .odp.
2. In Task pane click "Slide Transitions", Advance Slide - Automatically after 
1sec, then click Apply to all slides.
3. Press F5, wait for Impress to attempt showing fisrt several slides and 

I can provide .odp if becomes unavailable.
Comment 4 2fi 2009-06-02 07:50:41 UTC
i can reproduce it with files bigger than 500 KB
$ uname -a
Linux myhost 2.6.29-ARCH #1 SMP PREEMPT Wed May 20 06:42:43 UTC 2009 x86_64
Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz GenuineIntel GNU/Linux 1 GB RAM

Comment 5 wolframgarten 2009-06-02 08:01:35 UTC
@2fi: how do you know that this is the same problem? The first file is large and
.odp, your file is rather small and ppt. I do not think that this is the same cause.
Has anyone send a crash report and received an ID for it? I am downloading the
big file right now.
Comment 6 2fi 2009-06-02 09:18:55 UTC
@wg: i have the same problem with large odp and small ppt (large haven't tried).
I never got to the crash part because the computer hangs if i don't kill the
process .
Should i make another bug report for the ppt part?
Comment 7 wolframgarten 2009-06-02 11:46:17 UTC
On windows I get a runtime error after  short time. Reassigned.
Comment 8 kpalagin 2009-06-03 07:14:30 UTC
I suggest targeting for 3.1.1 as 3.0.0 plays slide show for both 
impress_test_file.odp (huge one) and class2.ppt (small one) just fine.
Comment 9 wolframgarten 2009-06-03 09:32:15 UTC
@2fi: yes, please file another issue and attach one of your files. Thanks.
Comment 10 nexonic 2009-06-03 22:34:01 UTC
@kpalagin: I have to shut down my server now. Would be great if you or someone
else could provide the file.
Comment 11 clippka 2009-06-09 17:34:28 UTC
@sun, I copied the bugdoc to so-data/qs/bugdoc/issuezilla/102380

The problem here is that this document needs 1.6 Gig memory, which causes a
swapping on most systems and swapping is a bad thing.

This is a regression to 3.0 since the automatically swap out for graphics does
not work anymore.

I change the target to 3.1.1 since this is a regression and also it is a very
severe one in my opinion. Each pixel graphic does not only need its file size
but its decompressed size in memory...
Comment 12 clippka 2009-06-10 14:25:07 UTC
*** Issue 102627 has been marked as a duplicate of this issue. ***
Comment 13 punisher 2009-06-10 17:00:01 UTC
NOTE: This issue affects odt documents too; thus, this is an application core
issues, as I mentioned in Issue 102627.

I have an 11 MB odt document, containing many graphics, that exhibits this same
problem.  I cannot attach the document due to contractual obligations.

Furthermore, I should point out the inconsistency I observer here in that @2fi
is told by wg to file another bug for his ppt-related issue and yet my Issue
102627 has been duped to this.  Personally, I believe it is all the same bug.
Comment 14 Armin Le Grand 2009-06-11 15:41:30 UTC
AW->punisher: This cannot influence odt douments in principle; Writer has it's
own implementation of Graphic objects (and it's own buffering/caching
mechanism). We currently work on joining those various objects to a single one,
but it's not the case yet. If You really see the same problem in Writer, please
write a new task for it.
Comment 15 punisher 2009-06-15 05:55:28 UTC
(reply to: aw)
> If You really see the same problem in Writer, please write a new task for it.

Just filed Issue 102773 for the memory leak + crash issue with writer.
Comment 16 Armin Le Grand 2009-06-22 15:10:57 UTC
AW: Adding to CWS aw074 to take a look...
Comment 17 Armin Le Grand 2009-06-26 17:45:54 UTC
AW: Okay, here we go. Base of consideration is the SdrGrafObj. GraphicObjects
which are swapped have a swap-pointer set to SdrGrafObj::ImpSwapHdl. When
(view-indeendent) primitives are created (SdrGrafPrimitive2D) from the
ViewContact (VC) inside
ViewContactOfGraphic::createViewIndependentPrimitive2DSequence the GraphicObject
is copied using the copy operator. At this copy, the swap-pointer is not copied.
In principle this is what is wanted; primitives are visualisation objects and
should only exist when the object actually gets visualized; thus it is okay that
the copy is not swapped. To make the swappig work again in principle it is just
necessary to flush the SdrGrafPrimitive2D and it's bufferd decomposition. The
primitives are also buffered at the ViewObjectContact (VOC), but as the name
says this only exists when a view is visualizing the object, so this is
automatically deleted.
That flushing can be done internally using
flushViewIndependentPrimitive2DSequence in the ViewContactOfGraphic
implementation; adding a method ViewContactOfGraphic::flushGraphicObjects() will
do that. A point to trigger this already exists in SdrGrafObj::ImpSwapHdl itself.

After doing this the swapping works as before. I also took a look at the swap-in
time for graphics. There is a mechanism in the ViewObjectContactOfGraphic which
allows asynch loading (using AsynchGraphicLoadingEvent which registers at the
view and is triggered using a timer). This is designed to show a replacement
graphic at first repaint, which at the event rigger, gets replaced and repainted.
That mechanism is currently broken since GraphicObject copy constructor triggers
the SwapIn hard; investigating how to avoid this...
Comment 18 Armin Le Grand 2009-06-30 10:34:36 UTC
AW: I have now finetuned
ViewContactOfGraphic::createViewIndependentPrimitive2DSequence to use more
cases; it will now locally create content for empty PresObjs
(createVIP2DSForPresObj), for swapped out (createVIP2DSForDraft, new) and for
regular visualisation. createVIP2DSForPresObj needs some finetuning fo robject
text and clipping it when the space (the object size) is not sufficient...
Comment 19 Armin Le Grand 2009-06-30 12:10:40 UTC
AW: createVIP2DSForDraft finetuning done. Text is now (as in DEV300 m29) taken
from Filename, else from ObjectName and extended by '...'. Graphic is the empty
graphic ressource (as in old versions). Graphic is only used when space is
sufficient. Text is clipped when space is not sufficient. When the GraphicObject
has no LineStyle, a gray outline is added.
Checked with the original bugdoc, works well. Maybe the on-demand load should be
suppressable. Discussing...
Comment 20 Armin Le Grand 2009-06-30 17:52:00 UTC
AW: Comitting chages up to now to not lose them.
Comment 21 Armin Le Grand 2009-07-03 12:43:01 UTC
AW: I compared behaviour with the DEV300 m29 (pre-Primitive version). The
difference is in GarphicObjects on the MasterPages; these were also swapped in
that version, but due to the MasterPageCache, it was never missing in the
visualisation. In the new version those garphics get swapped and show the
replacement object from time to time. I have to find a way to solve that (to not
swap those). This is from memory no problem, since the masterpage cache has
normally the same/a even bigger size than the graphic hold in memory. Looking
for possibel solutions...
Comment 22 Armin Le Grand 2009-07-03 13:48:29 UTC
AW: I made the bDoAsynchronGraphicLoading switch in
ViewObjectContactOfGraphic::createPrimitive2DSequence aditionally dependent from
being an object on a MasterPage. Switching through the pages looks now as
before. Checked in, done.
Comment 23 Armin Le Grand 2009-07-06 16:41:52 UTC
AW: Ckecked with build, works as expected.
Comment 24 Armin Le Grand 2009-07-07 09:57:02 UTC
AW->WG: Please reviewas described. The test file is where CL has described.
Comment 25 wolframgarten 2009-07-09 09:33:33 UTC
Verified in CWS.
Comment 26 wolframgarten 2009-07-30 11:33:10 UTC
Tested in m17. Closed.