Bug 447912 - weird-ass exception related crash
weird-ass exception related crash
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
: 446005 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-22 09:09 EDT by Caolan McNamara
Modified: 2008-06-03 06:51 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-03 06:51:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
preprocessed code (779.72 KB, text/plain)
2008-05-22 09:09 EDT, Caolan McNamara
no flags Details
original source, OleEmbeddedObject::TryToRetrieveCachedVisualRepresentation_Impl is the offender (68.19 KB, text/plain)
2008-05-22 09:11 EDT, Caolan McNamara
no flags Details
patch, which works around for no good reason that I can see (1.25 KB, text/plain)
2008-05-22 09:12 EDT, Caolan McNamara
no flags Details
build env (3.67 MB, application/x-gzip)
2008-05-29 10:58 EDT, Caolan McNamara
no flags Details
building script (1.12 KB, text/plain)
2008-05-29 11:02 EDT, Caolan McNamara
no flags Details
try and load this (1.45 MB, application/vnd.ms-powerpoint)
2008-05-30 14:48 EDT, Caolan McNamara
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 36419 None None None Never

  None (edit)
Description Caolan McNamara 2008-05-22 09:09:57 EDT
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.
Comment 1 Caolan McNamara 2008-05-22 09:09:57 EDT
Created attachment 306369 [details]
preprocessed code
Comment 2 Caolan McNamara 2008-05-22 09:11:29 EDT
Created attachment 306370 [details]
original source, OleEmbeddedObject::TryToRetrieveCachedVisualRepresentation_Impl is the offender
Comment 3 Caolan McNamara 2008-05-22 09:12:00 EDT
Created attachment 306371 [details]
patch, which works around for no good reason that I can see
Comment 4 Caolan McNamara 2008-05-22 09:16:22 EDT
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
Comment 5 Caolan McNamara 2008-05-29 10:58:43 EDT
Created attachment 307080 [details]
build env
Comment 6 Caolan McNamara 2008-05-29 11:02:37 EDT
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 :-(
Comment 7 Jakub Jelinek 2008-05-30 13:03:50 EDT
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.
Comment 8 Jakub Jelinek 2008-05-30 13:36:30 EDT
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.
Comment 9 Caolan McNamara 2008-05-30 14:48:57 EDT
Created attachment 307229 [details]
try and load this

Try and load this, and save as, and an output name of "output.odp"
Comment 10 Caolan McNamara 2008-06-02 17:32:03 EDT
*** Bug 446005 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Jelinek 2008-06-03 06:51:51 EDT
Let's track this only UPSTREAM.

Note You need to log in before you can comment on or make changes to this bug.