Description of problem: In practice: bug 446005 where impress documents can crash on export Version-Release number of selected component (if applicable): gcc-4.3.0-8.i386 How reproducible: every time Steps to Reproduce: and thats the tricky bit. I can't see anything wrong with the code, and just about any apparently irrelevant change to the particular source file results in it working. valgrind is silent on the matter except to say that there's an invalid write. gdb gives weird-ass results and claims a crash in the printf in the catch clause. And if I move methods out of the file into another one then at a certain stage it works, hampering my efforts to shrink a test-case. Here's what I *do* know. compiled like this it fails: g++ -c -Os -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic /tmp/ok.ii -o ../../unxlngi6.pro/slo/olepersist.o and that's our default for i386 OOo code like these three it works fine: g++ -c -O2 -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic /tmp/ok.ii -o ../../unxlngi6.pro/slo/olepersist.o g++ -c -Os -fno-strict-aliasing -fvisibility-inlines-hidden -fpic /tmp/ok.ii -o ../../unxlngi6.pro/slo/olepersist.o g++ -c -Os -freorder-blocks -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic /tmp/ok.ii -o ../../unxlngi6.pro/slo/olepersist.o i.e. if I drop either -fasynchronous-unwind-tables or add -freorder-blocks to -Os it works fine, but it also works like this g++ -c -O2 -fno-reorder-blocks -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic /tmp/ok.ii -o ../../unxlngi6.pro/slo/olepersist.o I also know that if I apply the following patch to the original code it *also* works. I also know that in that the successful case an exception is thrown on each iteration, i.e. output of... trying 0 still trying 0 success on 0 trying 1 failure on 1 trying 2 failure on 2 trying 3 failure on 3 trying 4 failure on 4 trying 5 failure on 5 trying 6 failure on 6 trying 7 failure on 7 trying 8 failure on 8 trying 9 failure on 9 while on the crashing case I get... trying 0 still trying 0 success on 0 trying 1 failure on 1 trying 2 failure on 2 trying 3 *ka-boom* Its as if somehow the repeated throwing and catching of the exception is somehow screwed when we get to the third catch attempt.
Created attachment 306369 [details] preprocessed code
Created attachment 306370 [details] original source, OleEmbeddedObject::TryToRetrieveCachedVisualRepresentation_Impl is the offender
Created attachment 306371 [details] patch, which works around for no good reason that I can see
This one has absolutely broken my heart, I can just stick in the workaround, but any hints as to a better way to track this down would be incredibly appreciated
Created attachment 307080 [details] build env
Created attachment 307081 [details] building script Well, this is a tarred up build env and a script to build the .ii against it. Unfortunately the only test-harness (and source of libs to link against) is OOo itself :-(
Can't reproduce unfortunately. Neither with the stock libemboleobj.so, nor with libemboleobj.so with -Os -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic compiled input.ii, nor with -Os -fno-strict-aliasing -fno-asynchronous-unwind-tables -fvisibility-inlines-hidden -fpic. All 3 save the .odp just fine, and in neither case anything is printed on stderr.
I've just checked and g++ -c -O2 -fno-strict-aliasing -fasynchronous-unwind-tables -fvisibility-inlines-hidden -fpic generates exactly the same .text as g++ -c -O2 -fno-strict-aliasing -fvisibility-inlines-hidden -fpic The only difference is the unwind info. So, if there is a way to reproduce it, e.g. libgcc_s could be instrumented to print details on where it passes control to during exception handling.
Created attachment 307229 [details] try and load this Try and load this, and save as, and an output name of "output.odp"
*** Bug 446005 has been marked as a duplicate of this bug. ***
Let's track this only UPSTREAM.