Bug 447912

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.