Apache OpenOffice (AOO) Bugzilla – Issue 86866
embeddedobj: sample .ppt that crashes on export to .odp
Last modified: 2013-08-07 15:31:14 UTC
The following .ppt on save as .odp crashes in TryToRetrieveCachedVisualRepresentation_Impl for me. The following sort of odd patch makes the problem go away. Is this reproducible on your side ?
Created attachment 52003 [details] is there something wrong with OUString::operator++
Mikhail, please have a look
Sorry, but the patch just replaces one string operation with another. Actually the operator+=() is used very often in the office, so I think that the change has just affected the memory usage so that there is no crash any more. Anyway it will need further investigation.
mav->cmc: Could you please provide the mentioned .ppt document. :)
Created attachment 53279 [details] sample .ppt
zhangxiaofei->mav: I cannot reproduce the crash with DEV300_m10 and OOG680_m6 on Fedora 8, could you help me to verify please?
As I understand the problem was reproducible on OOH680m9. But since the bug has OOo3.0 target it is enough that it works in OOo3.0. mav->cmc: Could you please verify the the scenario works well on DEV300/m10 on your environment as well. mav->zhangxiaofey: Could you please try to reproduce it on OOH680m9 when you have time and if it is reproducible investigate it with valgrind. It is possible that the changes in source code have affected memory allocation and the existing memory corruption just does not cause crash any more. It would be nice to understand the cause for the crash if it is reproducible in OOH680m9 with your system.
https://bugzilla.redhat.com/show_bug.cgi?id=446005 I'm sort of sure that this may be a compiler problem of some kind, I find that a) making olepersist.cxx NOOPT and it works, or b) if I drop -fasynchronous-unwind-tables from our iX86 compiler flags it works, or c) if I remove uno::Reference< io::XStream > xCachedCopyStream; and add it inside each try block it works In the crashing case, all is well until after the catch of the thrown exception, at which point the next loop fails, and valgrind just says value 0xa not malloced recently. Adding debugging prints and the problem just moves to another statement inside the loop. Adding -O0 and the problem goes away, making it super-hard to determine where the error is with gdb as most things are optimized away otherwise. If I could isolate it standalone then at least I could properly blame gcc, but finding that hard to achieve.
mav->cmc: Unfortunately the problem is not reproducible on our side ( neither in OOH680 nor in DEV300 ). Which version of gcc are you using? Moving the issue to 3.x
gcc 4.3.0. Personally I'm now convinced its not an error in the code but somewhere in the toolchain.
jakub has done some awesome debugging for us and isolated the problem as one in gcc : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36419 closing "invalid" for OOo.
closing, see gcc bugzilla
to mark as dup
mark as dup *** This issue has been marked as a duplicate of 89764 ***
close as duplicate