Issue 104509

Created attachment 64381 [details]
A sample file  i got crash

To produce this error you need to copy then paste and then once again copy an
object. A flag for example in attached file.

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 ?

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.

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?

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.

Ubuntu builds are not the original builds. Sorry, still not reproducible when
copying and pasting the slide in the slide pane on the left.

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.

Still not reproducible  here. @  niravce111: can you provide an Error id which
you receive when you send an error report?

Created attachment 64569 [details]
Following error report i got

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.")

Created attachment 64650 [details]
I got this error report and my report id is r3m83dc

Reassigned. @af: anything visible from the stack? Still not reproduced by me.

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 (frank.loehmann@sun.com) is from
February. Is the database up to date?

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.

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.

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

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.

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.

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.

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.

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.

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.

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."

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.

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.

(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)

(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

Link to 1129kb-image-crash.odp
https://docs.google.com/presentation/d/192mmmhQuYIN8IY0S34R2uFak2u1apcCcAQ6f-dZkc4Y/edit?usp=sharing

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.

Reset the assignee to the default "issues@openoffice.apache.org".

All versions (AOO and Windows) are end-of-life status.
Please try to update first and report back if this issue still occurs.