Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Impress crashes when editing file with many graphical objects|
|Component:||editing||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Priority:||P2||CC:||duncan.nisbet, elderthing, felix_chang, framire8, ianbrock2000, issues, jimmore295, jvt, mbluett88, rc_oo_bugzilla, rohrmanj, whairst|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description aghast 2009-08-26 06:07:40 UTC
OOo impress crashes when editing a large presentation file with many embedded graphical objects. Tested 300m15 and 310m11 builds. Impress often crashes if i copy and then paste an object more then once. A second and rarely third paste crashes an app. And i cannot find a log file with this error to attach here.
Comment 1 aghast 2009-08-26 06:14:36 UTC
Created attachment 64381 [details] A sample file i got crash
Comment 2 aghast 2009-08-26 06:21:00 UTC
To produce this error you need to copy then paste and then once again copy an object. A flag for example in attached file.
Comment 3 wolframgarten 2009-08-26 07:55:20 UTC
Corrected priority. Please have a look at http://qa.openoffice.org/scdocs/ddIssues_EnterModify.html#priority . Have you been asked to send a crash report and did you do so? Which error ID did you receive? Do you use an original version from OOo or from some other distributor/builder ?
Comment 4 aghast 2009-08-26 22:50:10 UTC
No, I have not. I didn't received any ID of errors. I used an impress from https://launchpad.net/~openoffice-pkgs/+archive/ppa both for Ubuntu hardy and jaunty. Also i tried an original version of OOo.
Comment 5 wolframgarten 2009-08-27 07:50:05 UTC
Versions from other distributors do not show the crash reporter, only the original OOo version does. It makes me wonder why it did not come up here... If we cannot reproduce it and do not have a crash stack available we cannot do much about it. I open the file, copy the flag using the keyboard and insert it several times on the same slide and on a new slide , too. Is this correct?
Comment 6 aghast 2009-08-27 23:07:11 UTC
Not exactly. I recieved an error when i copy a whole slide into a clipboard through a gui menu (right mouse button - copy ), then i paste a slide from a clipboard (RMB - paste). Thus i got two slides. All went fine at this moment. Later i once again copy first slide or another one and then error appears. And as i mentioned before i have not got any error id when i tried an original OOo such as ubuntu builds.
Comment 7 wolframgarten 2009-08-31 14:58:51 UTC
Ubuntu builds are not the original builds. Sorry, still not reproducible when copying and pasting the slide in the slide pane on the left.
Comment 8 niravce111 2009-09-02 08:27:23 UTC
Niravkumar Patel (09/02/2009) I am able to replicate the same bug successfully on Windows XP. I am writing here because bug is also reproducible on Windows XP so it’s a broader issue. System Configuration: HP Pavilion Microsoft Windows XP Home edition version 2002 Service pack 2 Intel(R) Celeron(R)M 1.60 GHZ 504 MB RAM Open Office version: OOo-dev 3.2x (codeline DEV300) Steps for replicating the bug: Use the impress file attached by reporter. 1. Open impress file 2. Copy the slide in the slide pane by Right click of mouse(Copy the last slide in the slide pane) 3. Paste the slide in the slide pane by Right click of mouse 4. Repeat step 2 and 3 respectively impress will crash after 2 to 5 attempt. (max 10 attempts)It will show recovery window. If I decline to recover and after decline to save WRITER opens automatically. If I recover then impress opens but after doing the steps it crashed. If you have trouble getting bug then restart the computer and try the steps.
Comment 9 wolframgarten 2009-09-03 11:46:42 UTC
Still not reproducible here. @ niravce111: can you provide an Error id which you receive when you send an error report?
Comment 10 niravce111 2009-09-05 20:23:17 UTC
Created attachment 64569 [details] Following error report i got
Comment 11 wolframgarten 2009-09-07 09:00:24 UTC
Did you send this error report? Then you should get a reply with an error id in it (something like "The ID of the error report is rhj99dc.")
Comment 12 niravce111 2009-09-09 18:48:55 UTC
Created attachment 64650 [details] I got this error report and my report id is r3m83dc
Comment 13 wolframgarten 2009-09-10 09:55:01 UTC
Reassigned. @af: anything visible from the stack? Still not reproduced by me.
Comment 14 frank.loehmann 2009-10-15 13:18:23 UTC
I have the same problem problem on my system @home. Copy and paste (or move & copy) of photos sometimes causes a crash. Could not find my reports in the in-house report tooling. Last report from me (email@example.com) is from February. Is the database up to date?
Comment 15 cfeilberg 2010-03-28 04:48:37 UTC
All tests I've done was on Samsung NC10, 1 Gb memory, XP SP3. OO-version DEV300m75. (build: 9488). Summng previous comments on this issue it appears to have at least five ways of being reproduced. I've tried to check these five: #1: Copy the flag, paste it, copy an object (any) => crash. #2: Copy+paste an object more than once (2-3 times) => crash. #3: Copy whole slide+paste it (through right-click-menu using mouse). #4: Copy last slide in slide pane + paste it. Repeat this 3-5 times => crash. (if not, reboot and retry) #5: Copy + paste photos "sometimes" => crash. I haven't been able to crash impress by recreating any of these scenarios on DEV300m75. I have made these observations while checking: Observation A: When pasting a whole slide there's a step deciding to put the slide before or after. This step is not documented in previous descriptions. Anyway it is not adding value when you try to paste as last slide (there's no logical 'before' or 'after'....) and it's confusing, since you indicate a space between slides with the mouse in order to paste. I will regard this as a choice that should only appear if you press paste while the mouse hovers over a slide in the slide pane, as otherwise the question is meaningless. Observation B: The test file contains a flag, which consists of (4 lines) grouped with a group of 1 polygon, 1 textbox, 1 picture (?). Besides that there are 2 textboxes and a rectangle on the slide. Thus the test slide cannot be regarded as an extreme case. Observation C: In order to try to crash Impress, I did some additional regrouping by selecting all objects on slide, grouping them, copy it, regrouping all again (in effect doubling the number of items in a group). Then I copied the whole slide a number of times. This resulted in minute-long waiting times, while CPU was running on 50% and memory was allocated in small chunks. Meanwhile Impress was unresponsive. At around 25 slides the waiting time amounted to 2-3 minutes for each of the operations: right mouse click | select copy | right mouse click | select paste | select before / after, with most waiting time on "select copy" and "select paste". I wonder why there's waiting time on the other operations. Observation D: Memory seems to be allocated, no matter what the user activates. Why is more memory needed to show right click menu ? Observation E: Trying to go to extremes I selected all 25 slides to copy and paste them through slide pane, using mouse operations. This amounted to 6 minutes time, where Impress was unresponsive. Total memory use at that time (with Firefox, Thunderbird and Windows explorer open too) was 945Mb. Impress alone took up 610Mb. Notice that niravce111 did get a crash on a machine with 504 Mb RAM. However, on my machine Impress came back and seemed stable, but was horrifying slow to work with. Eventually I killed it, and it was a slow death: around 3 minutes. This could indicate that it's the machine's RAM-control, but I don't know what happens when you press the X-button, and XP asks: it's not responding - stop it now or wait?. I chose stop it now. Theory and followup-tests: Memory usage looks strange. First it is allocated in small chunks, which is time consuming. It ought to be simple to estimate the memory needed for copying another object, which already exists in the presentation and claim it in one scoop. This has a devasting effect on performance and should be logged as a bug on its own. On smaller machines (memorywise) the extreme memory used could be the crash culprit. Followup-suggestions: Checking bug database for reports on bad performance and/or memory usage. There might be a connection. Checking the 5 scenarios on virtual machines, where memory can be set down to a smaller value, like 500 Mb. Checking if the "paste before or after"-dialogue is newly added or exists in the older versions the bug is originally reported on (I couldn't find a way to obtain those, sorry). Checking on the older version Checking on a machine without Memory swap file (re observation E). Checking bug database for existance of bugs mentioned in Observation A and D.
Comment 16 fitorion 2010-09-11 22:27:24 UTC
Could not reproduce. Running Windows 7 and OOo-Dev_3.3.0beta1_Win_x86 I ran through the suggested methods to reproduce it posted here. The only anomalous behavior occurred when repeatedly pasting the flag. For less than 1 minute the program would not respond to me clicking on the flags. During this time I could change the layout so the rest of the program appeared to be running normally.
Comment 17 justinrohrman 2011-03-05 22:58:00 UTC
OOO Impress Version: OOo-dev 3.4.0 DEV300m99 (Build:9570) OS: Windows 7 Professional Image size: 70 K Status: I am unable to reproduce an Impress crash through copy / paste operations Tests I ran: Test 1: Copy and past an image several times into a single slide *I pasted an image on a single slide 10+ times without seeing a failure modes of copy paste tested: Right click menu Menu bar ctrl C / ctrl V Test 2: Copy and paste a slide with a single image several times *I did this 30+ times without seeing a failure modes of copy paste tested: Right click menu Menu bar ctrl C / ctrl V Test 3: Copy and paste a slide with many images several times *I did this 30+ times without seeing a failure modes of copy paste tested: Right click menu Menu bar ctrl C / ctrl V Test 4: Sequential copy and paste a slide with many images several times *This means copy and then paste and then copy again and paste again and so on *I did this 30+ times without seeing a failure modes of copy paste tested: Right click menu Menu bar ctrl C / ctrl V
Comment 18 Jose Trigueros 2011-09-28 20:20:08 UTC
System Configuration: Ubuntu 32-bit 11.04 DEV300m106 I followed the instructions posted by the author of the bug post and I was not able to reproduce the bug. These are the steps that I followed: -Install a copy of the developer snapshot, I only have access to the latest one, which is version DEV300m106 ( note that this differs from the initial bug report, but it doesn't make sense to test on an old version if the new build does not have this bug ) -Download the test.odp that was provided by the bug report author. -Open Impress and open the provided file. -Copy the object that is already included in the file 20 times or until it crashes. I figure that if the bug is reproducible, I'll be able to see the crash on the second to third copy-paste. Note: Copy was done using keyboard shortcut and using the right-mouse button The bug seems to not be happening in this version of Impress, it would be helpful if the author could try it on the newer version and see if the problem persists, this way we can dig in further and see if it was a problem with the user set up or with OO itself.
Comment 19 framire8 2012-10-01 04:16:47 UTC
System: Windows 7 Enterprise OO 3.4.1 I replicated bug by attempting to edit and adding pictures onto a Writer. First, I added a picture, drag and drop from Google images(91KB) onto Writer. Image does not display, only shows image name. Second, Writer crashes when drag-and-drop multiple pictures back-to-back. Not all images successfully loaded. Also, when resizing those images OO Writer does not respond.
Comment 20 Rob Weir 2013-02-02 02:57:09 UTC
This Issue requires more information ('needmoreinfo'), but has not been updated within the last year. Please provide feedback as requested and re-test with the the latest version of OpenOffice - the problem(s) may already be addressed. You can download Apache OpenOffice 3.4.1 from http://www.openoffice.org/download Please report back the outcome of your testing, so this Issue may be closed or progressed as necessary - otherwise the issue may be Resolved as Invalid in the future.
Comment 21 rc_oo_bugzilla 2013-11-12 05:48:31 UTC
I attempted to replicate this issue with the attached sample file following the steps laid out in comments number 15 and 17. I ran the tests on a VirtualBox guest running Windows XP. System Information: Host: Lenovo T410 i5 2.4 GHz 4 GB RAM Windows XP SP3 VirtualBox Version: 4.2.0r80737 Guest: Windows XP SP3 512 GB RAM OpenOffice Build: Apache_OpenOffice_4.1.0_Win_x86_install_en-US.exe_1540294.exe I was not able to replicate the crashes. During testing, I monitored CPU and memory usage and did not see any issues with the CPU pegging out or memory not being released.
Comment 22 felix 2013-11-12 12:59:53 UTC
Using a window 7 machine with OpenOffice 4.0.1 , I am unable to duplicate the crash using sample file. I went ahead and used a image file instead. Doing a copy and paste on the image with 40 copies of it, I am still unable to duplicate the result.
Comment 23 jimmore295 2013-11-14 18:24:17 UTC
Two methods have been reported to cause this crash. The first is to copy an image repeatedly, and the seconds is to drag and drop an image repeatedly. I am unable to reproduce this crash using either method. I copied the flag in sample document onto its same slide 27 times. I used control-c for the copy and control-v for the paste. I continued by dragging and dropping a 2800x990px image onto a second slide 10 times. I then used control-c and control-v to append a copy of this new slide 198 times bringing the number of slides to a total of 200. Throughout all this the system remained stable and I was unable to reproduce this defect. I tested on Win 7 with Open Office 4.0.1 on a system with 2Gb of RAM.
Comment 24 elderthing 2014-06-14 19:18:29 UTC
I attempted to recreate this bug under Windows 8 and Apache Open Office version version 4.1.0. I began by copying high resolution images into new slides. I began with the drag and drop method, putting them before, after, or on top of existing slides. This did not create any issues, even after ten or twenty tries. I then turned to keyboard shortcuts. Doing this I was able to create approximately 400 new slides in seconds. This crippled the program entirely. After 20 minutes, it's still unresponsive. Saving extremely large files seems to cause issues, as does queing multiple processes. This doesn't seem to be an issue with any reasonable amount of activity, and could be an edge case. On the other hand, it's not a very graceful handling of requests. Ideally, the system would detect the massive queue of transactions and ask the user to confirm their intent, instead of collapsing under the crippling load. If I'm dealing with the same issue as the crash reports earlier, it appears to be a bug resulting from Apache's handling of load. The computer did not slow, but the software became entirely unresponsive. Note, I didn't crash the software, but depending on how your system handles unresponsive programs, that might be possible to trigger. Use the impress file attached by reporter. 1. Open a new impress file 2. Create some slides. 3. Paste a high res image into one of the slides in the side panel. 4. Using right click, or keyboard shortcuts, paste new images into slides, or create new slides with images. 5. Repeat 3-4 Here are my system specs: 4 gigs ram. 2400 ghz processor 160 gigs hard drive space."
Comment 25 Andy 2014-08-17 00:43:54 UTC
I'm having the same trouble. I create a presentation (.ppt format) that is a series of images. Presentation is actually made up of slides copied from other presentations, just in a different order. Impress usually gets really sluggish (like several seconds just to change slides), starts failing to show slide previews on the left, sometimes fails to show the image portion of the slides, then crashes. Typically I get 3-4 crashes each time I try to build one of these presentations - VERY repeatable on my system. Potentially useful hint: soffice.bin is using a HUGE amount of memory - Task Manager reports Mem Usage + VM Size to be 1.5 GB or higher. Finished presentation size is only 2 MB. I'm running WinXP SP3 32 bit with 2 GB or RAM.
Comment 26 Ian 2015-01-09 08:46:49 UTC
I have presentation files successfully created/edited pre 4.0 but now cannot even view more that 4 pages without it crashing. There is no crash file and OO just 'vanishes'. Tried to 'cheat' the system and export pdf...boom!! Running under Windows Vista and 7 with file sizes up to 25M over 20'ish pages each with embedded picture.
Comment 27 Duncan Nisbet 2015-04-19 23:39:56 UTC
(Duncan Nisbet, BBST Student, 04/20/15) I was able to reproduce the crash with the following configuration: AOO Version: AOO411m6 (Build:9775) - Rev. 1617669 Machine: Windows 7 (service pack 1) AMD Athlon II P320 2.10 GHz 3.75GB usable RAM Unfortunately the Error Report Tool did not launch with this crash in this version of the app. Why am I adding another comment? This report has 26 comments spanning 5.5 years and it is still UNCONFIRMED. I hope my comment contains enough new information to help progress the bug towards some resolution. Steps to reproduce I have been able to reproduce the crash 100% of the time with the following steps. Required: Impress presentation with an image > 1mb on 1 slide. I used attached 1129kb-image-crash.odp 1. Open attached 1129kb -image-crash.odp (contains 1 slide with 1 static image) 2. Copy & paste slide (keyboard shortcuts, right click options or menu options) 3. Paste slide again (no need to copy again) 4. Impress crashes This is similar to the behaviour observed in Comment 8; only I had to include a large image (1.1mb) Also, the test above is similar to Test 2 in Comment 17 (which did not reproduce the crash), but again I used a larger image (1.1mb vs I assume 70kb) The crash was also observed with the following deviations from the steps above when running follow up tests: • Creating a new presentation and inserting multiple large images (how I created 1129kb -image-crash.odp) • Create a new slide & copy image from slide 1 to that new slide • With 2 slides, both with the same large image, attempt to copy 2nd slide The crash was not observed when repeating the following tests • Follow steps above but with cut & paste instead of copy & paste (is this related to a buffer being overrun when copying which isn’t being overrun when cutting?) • File sizes < 1mb did not crash Impress with the steps outlined above. (997kb-image-nocrash.odp) • Mp4 files > 1mb (not even mp4 > 30mb!) Further suggested follow up tests • What different objects reproduce the behaviour (static images do, video files apparently don’t) • Repeat steps with images closer to the 1000mb threshold • What program options are available that might impact copy & paste functionality? • Possibly altering system memory – although like previous commenters, my machine showed no CPU performance or memory spikes when Impress crashed Speculation of underlying fault Is there a 1mb buffer that is being blown when copying? When cutting, I am assuming that the buffer is not being exceeded therefore the program does not crash. This is an assumption on behalf of the commenter. I was unable to get images closer to the 1000mb threshold, nor see the size of the content on the clipboard. Customer Impact / bug importance Quality & therefore size of media is growing & has grown immensely over the past 5 years – think of the smartphone & the associated camera quality wars. Also a similar increase in the DSL camera market. People are taking high quality photos & recordings & they want to use those in presentations to show off their work to the best of their abilities. The range of different images & other media being used is greater than when this bug was raised – what does that mean for it’s importance? There are even example use cases in the comments in this bug outlining how those commenters are using Impress (e.g. comments 25 & 26) Other notes • On recovering the document, the Error Report Tool did not automatically open as the message informed me it would. • Some of the comments are distracting from the investigation of this bug, such as comment 26 which appears to be related to exporting to pdf (see issue 101669)
Comment 28 Duncan Nisbet 2015-04-19 23:52:04 UTC
(In reply to Duncan Nisbet from comment #27) > (Duncan Nisbet, BBST Student, 04/20/15) > > I was able to reproduce the crash with the following configuration: > AOO Version: AOO411m6 (Build:9775) - Rev. 1617669 > Machine: Windows 7 (service pack 1) AMD Athlon II P320 2.10 GHz 3.75GB > usable RAM > > Unfortunately the Error Report Tool did not launch with this crash in this > version of the app. > > Why am I adding another comment? > This report has 26 comments spanning 5.5 years and it is still UNCONFIRMED. > I hope my comment contains enough new information to help progress the bug > towards some resolution. > > Steps to reproduce > I have been able to reproduce the crash 100% of the time with the following > steps. > Required: Impress presentation with an image > 1mb on 1 slide. I used > attached 1129kb-image-crash.odp > 1. Open attached 1129kb -image-crash.odp (contains 1 slide with 1 static > image) > 2. Copy & paste slide (keyboard shortcuts, right click options or menu > options) > 3. Paste slide again (no need to copy again) > 4. Impress crashes > > This is similar to the behaviour observed in Comment 8; only I had to > include a large image (1.1mb) > > Also, the test above is similar to Test 2 in Comment 17 (which did not > reproduce the crash), but again I used a larger image (1.1mb vs I assume > 70kb) > > The crash was also observed with the following deviations from the steps > above when running follow up tests: > • Creating a new presentation and inserting multiple large images (how I > created 1129kb -image-crash.odp) > • Create a new slide & copy image from slide 1 to that new slide > • With 2 slides, both with the same large image, attempt to copy 2nd slide > > The crash was not observed when repeating the following tests > • Follow steps above but with cut & paste instead of copy & paste (is this > related to a buffer being overrun when copying which isn’t being overrun > when cutting?) > • File sizes < 1mb did not crash Impress with the steps outlined above. > (997kb-image-nocrash.odp) > • Mp4 files > 1mb (not even mp4 > 30mb!) > > Further suggested follow up tests > • What different objects reproduce the behaviour (static images do, video > files apparently don’t) > • Repeat steps with images closer to the 1000mb threshold > • What program options are available that might impact copy & paste > functionality? > • Possibly altering system memory – although like previous commenters, my > machine showed no CPU performance or memory spikes when Impress crashed > > Speculation of underlying fault > Is there a 1mb buffer that is being blown when copying? When cutting, I am > assuming that the buffer is not being exceeded therefore the program does > not crash. > This is an assumption on behalf of the commenter. I was unable to get images > closer to the 1000mb threshold, nor see the size of the content on the > clipboard. > > Customer Impact / bug importance > Quality & therefore size of media is growing & has grown immensely over the > past 5 years – think of the smartphone & the associated camera quality wars. > Also a similar increase in the DSL camera market. > > People are taking high quality photos & recordings & they want to use those > in presentations to show off their work to the best of their abilities. > The range of different images & other media being used is greater than when > this bug was raised – what does that mean for it’s importance? > There are even example use cases in the comments in this bug outlining how > those commenters are using Impress (e.g. comments 25 & 26) > > Other notes > • On recovering the document, the Error Report Tool did not automatically > open as the message informed me it would. > • Some of the comments are distracting from the investigation of this bug, > such as comment 26 which appears to be related to exporting to pdf (see > issue 101669) Link to 1129kb-image-crash.odp https://docs.google.com/presentation/d/192mmmhQuYIN8IY0S34R2uFak2u1apcCcAQ6f-dZkc4Y/edit?usp=sharing
Comment 29 Duncan Nisbet 2015-04-19 23:52:35 UTC
Link to 1129kb-image-crash.odp https://docs.google.com/presentation/d/192mmmhQuYIN8IY0S34R2uFak2u1apcCcAQ6f-dZkc4Y/edit?usp=sharing
Comment 30 Mike Bluett 2015-09-12 23:55:45 UTC
Windows 7 Home SP1, ASUS n61VGseries laptop, 4G memory, Duo P8700 CPU. Office 4.1.1. Impress crashes intermittently. Avg of 1.6MB per photo file that is inserted into each slide. 3.2G memory used before staring Impress. 3.5G memory used just after opening the 29MB file. Then it drops down to 3.3G after a few seconds. Two times Impress crashed after loading a file size of 29MB. Adding one more file of size 2MB crashed Impress. No opportunity to send a report as the recovery window is unresponsive. Necessary to kill OpenOffice to get rid of the unresponsive report window. After restarting Impress for the 3rd time I was able to add 7 more slides without a crash having a total file size of 48.89MB. The crash occurred when trying to scroll through the set of slides from bottom to top. This time the recovery window did not hang and I was able to perform the recovery. After a successful recovery added a new slide, removed the frames inside the default slide, successfully inserted the next image of 2MB, as soon as I tried to resize the image by dragging from the top right corner Impress crashed. After the next recovery I successfully added 6 more slides (each having an inserted image). No further crashes occurred while doing this and each time resizing the image to fit the entire white window space. The entire file is 60MB containing 33 slides.