[llvm-bugs] [Bug 24792] New: exception handling crashes on i386 only when using -Os optimization, maybe stack unwind bug

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24792

            Bug ID: 24792
           Summary: exception handling crashes on i386 only when using -Os
                    optimization, maybe stack unwind bug
           Product: tools
           Version: 3.7
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: opt
          Assignee: unassignedbugs at nondot.org
          Reporter: truckman at FreeBSD.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 14870
  --> https://llvm.org/bugs/attachment.cgi?id=14870&action=edit
simple test case to reproduce exception handling crash

I've seen a number of crashes in the code for OpenOffice whose commonality is
exception handling.  This only occur when the code is compiled with -Os
optimization and only on i386.  The code operates correctly when compiled with
-O2 optimization.  If the code is compiled on amd64, it operates correctly with
any optimization level.

Compiling with either of these compiler versions results in crashing
executables:

clang version 3.7.0 (tags/RELEASE_370/final)
Target: i386-unknown-freebsd11.0
Thread model: posix

FreeBSD clang version 3.6.1 (tags/RELEASE_361/final 237755) 20150525
Target: i386-unknown-freebsd11.0
Thread model: posix

Clang versions 3.4 and 3.5 do not exhibit this problem.

The attached code fails with this stack trace when compiled with DEBUG
undefined:

% c++ -Os clangexceptionbug.cxx 
% gdb a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols
found)...
(gdb) run
Starting program: /home/dl/a.out 
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x08048808 in typeinfo for X ()
(gdb) bt
#0  0x08048808 in typeinfo for X ()
#1  0x080487ba in main ()
(gdb) 


With DEBUG defined:

% c++ -Os -DDEBUG clangexceptionbug.cxx
% gdb a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols
found)...
(gdb) run
Starting program: /home/dl/a.out 
(no debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...X ctor this=0x28612044
caught exception
X dtor this=0x28612044
X dtor this=0xffffdbd8

Program received signal SIGSEGV, Segmentation fault.
0xffffdbf8 in ?? ()
(gdb) bt
#0  0xffffdbf8 in ?? ()
#1  0xffffdbd8 in ?? ()
#2  0x0804879a in _start1 ()
Previous frame inner to this frame (corrupt stack?)
(gdb) 


In the OpenOffice code I saw a case where the value of "this" in a destructor
was offset by 4 bytes from the value of "this" in its matching constructor, but
I was unable to produce a simple test case to reproduce that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150912/d95d5e44/attachment.html>