https://bz.apache.org/ooo/show_bug.cgi?id=104509
Duncan Nisbet <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #27 from Duncan Nisbet <[email protected]> --- (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) -- You are receiving this mail because: You are on the CC list for the issue.
