[Bug c++/16027] New: Enabling optimisation causes segfault

["s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>]

Hi,

I'll apologise now for being less than specific - I think this is a problem in 
GCC's optimiser and it exists in both GCC 3.4.0 and 3.2.2. I am running an i686 
build on an AMD Athlon XP, RedHat 9.

Basically the problem is that my code runs fine without the optimiser on but 
calls the wrong memory allocator function as soon as optimisation is enabled. To 
be specific:

This works:
          "-fdefer-pop",
          "-fmerge-constants",
          "-fthread-jumps",
          "-floop-optimize",
          "-fif-conversion",
          "-fif-conversion2",
          "-fdelayed-branch",
          "-fguess-branch-probability",
          "-fcprop-registers",
          
          "-fforce-mem",
          "-foptimize-sibling-calls",
          "-fstrength-reduce",
          "-fcse-follow-jumps",
          "-fcse-skip-blocks",
          "-frerun-cse-after-loop",
          "-frerun-loop-opt",
          "-fgcse",
          "-fgcse-lm",
          "-fgcse-sm",
          "-fgcse-las",
          "-fdelete-null-pointer-checks",
          "-fexpensive-optimizations",
          "-fregmove",
          "-fschedule-insns",
          "-fschedule-insns2",
          "-fsched-interblock",
          "-fsched-spec",
          "-fcaller-saves",
          "-fpeephole2",
          "-freorder-blocks",
          "-freorder-functions",
          "-fstrict-aliasing",
          "-funit-at-a-time",
          "-falign-functions",
          "-falign-jumps",
          "-falign-loops",
          "-falign-labels",
          "-fcrossjumping",
          
          "-finline-functions",
          "-fweb",
          "-frename-registers"

This does not work:
          "-Os",
          "-fno-defer-pop",
          "-fno-merge-constants",
          "-fno-thread-jumps",
          "-fno-loop-optimize",
          "-fno-if-conversion",
          "-fno-if-conversion2",
          "-fno-delayed-branch",
          "-fno-guess-branch-probability",
          "-fno-cprop-registers",

          "-fno-force-mem",
          "-fno-optimize-sibling-calls",
          "-fno-strength-reduce",
          "-fno-cse-follow-jumps",
          "-fno-cse-skip-blocks",
          "-fno-rerun-cse-after-loop",
          "-fno-rerun-loop-opt",
          "-fno-gcse",
          "-fno-gcse-lm",
          "-fno-gcse-sm",
          "-fno-gcse-las",
          "-fno-delete-null-pointer-checks",
          "-fno-expensive-optimizations",
          "-fno-regmove",
          "-fno-schedule-insns",
          "-fno-schedule-insns2",
          "-fno-sched-interblock",
          "-fno-sched-spec",
          "-fno-caller-saves",
          "-fno-peephole2",
          "-fno-reorder-blocks",
          "-fno-reorder-functions",
          "-fno-strict-aliasing",
          "-fno-unit-at-a-time",
          "-fno-align-functions",
          "-fno-align-jumps",
          "-fno-align-loops",
          "-fno-align-labels",
          "-fno-crossjumping"

It doesn't matter if you choose -O1, -O2 or -O3 either. From the GCC sources, I 
figure that -Os does the least optimisation and thus is closest to -O0. It would 
also appear than GCC performs certain optimisations even if I turn all of them 
off like above.

I don't know if this is related but the post at http://lists.trolltech.
com/qt-solutions/2004-03/msg00000.html seems to refer to the same problem.

A gdb backtrace of the crash is as follows:

[ned@katey2 bin]$ gdb TestCapSpeed
GNU gdb 6.0
Copyright 2003 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 "i686-pc-linux-gnu"...
(gdb) run
Starting program: /home/ned/Tornado/bin/TestCapSpeed
[New Thread 1081350432 (LWP 23687)]
WARNING: Tn::TKernel has no capabilities defined for it
2004/06/16 21:57:07:3:none:(nil):0:Booted system
WARNING: TestCapSpeed has no capabilities defined for it
[New Thread 1084026160 (LWP 23691)]
Thread 1084026160 (Tn shell primary event loop) started
Received notification of creation of loop 0x0x84e7760
Created event loop 0x0x84e7760 in thread 1084026160
0 secs difference
Local Tn kernel v0.1 found!
[New Thread 1084628272 (LWP 23692)]
Thread 1084628272 (Tn component event loop) started
Received notification of creation of loop 0x0x84e80f8
Created event loop 0x0x84e80f8 in thread 1084628272
This is the Tn portable multithreaded kernel v0.1 (built: Jun 16 2004 21:55:08)
(C) 2002-2004 Niall Douglas. All Rights Reserved
Running on POSIX.2 (Linux [2.4.20-20.9] kernel) version 199209, i486 
architecture

[New Thread 1085156656 (LWP 23693)]
QDICTDYNRESIZE at namespace/NodeBase.cxx:128 resizing 0x847f420 from 13 to 1 
(load 3)
[New Thread 1085685040 (LWP 23694)]
WARNING: Unable to lock memory pages, does this process have sufficient 
privilege?
Thread 1085156656 (Pool thread) started
Thread 1085685040 (Thread pool time keeper) started
TestCapSpeed: TnFOX/src/FXMemoryPool.cxx:429: void FX::free(void*, FX::
FXMemoryPool*): Assertion `_p[2]==*(FXuval *) "FXMPFXMP"' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread 1084628272 (LWP 23692)]
0xffffe002 in ?? ()
(gdb) bt
#0  0xffffe002 in ?? ()
#1  0x42027561 in raise () from /lib/tls/libc.so.6
#2  0x42028b93 in abort () from /lib/tls/libc.so.6
#3  0x42020f95 in __assert_fail () from /lib/tls/libc.so.6
#4  0x0824477b in FX::free(void*, FX::FXMemoryPool*) (p=0x84bb288, heap=0x0)
    at TnFOX/src/FXMemoryPool.cxx:429
#5  0x081081a7 in std::_List_base<FX::FXString, std::allocator<FX::FXString> >::
_M_put_node(std::_List_node<FX::FXString>*) (this=0x84bb274, __p=0x0)
    at fxmemoryops.h:112
#6  0x08106893 in std::_List_base<FX::FXString, std::allocator<FX::FXString> >::
_M_clear() (this=0x84bb274) at list.tcc:78
#7  0x08130b91 in ~_List_base (this=0x84bb274) at stl_list.h:328
#8  0x0813082a in ~list (this=0x84bb274) at qstringlist.h:43
#9  0x08130804 in ~QValueList (this=0x84bb274) at qstringlist.h:43
#10 0x081307de in ~QStringList (this=0x84bb274) at TTaggedData.h:34
#11 0x081df23d in ~FXDirPrivate (this=0x84bb258) at TnFOX/src/FXDir.cxx:70
#12 0x081dd720 in ~FXDir (this=0x40a613f0) at TnFOX/src/FXDir.cxx:298
#13 0x08106542 in Tn::TKNamespace::DirNodePrivate::createEntries(FX::FXString 
const&) (this=0x84bf29c, path=@0x40a614e4) at FXDir.h:179
#14 0x080fa6ba in DirNode (this=0x84bee38, kernel=0x84c067c,
    parent=@0x84c0c1c, path=@0x40a614e4, icon=0x0) at namespace/DirNode.cxx:38
#15 0x080d7672 in StorageNode (this=0x84bee38, kernel=0x84c067c,
    parent=@0x84c0c1c) at namespace/StorageNode.cxx:43
#16 0x080913bc in Tn::TKernel::execute(FX::FXApp*) (this=0x84c067c,
    app=0xbfffe1dc) at TKernel.cxx:564
#17 0x082edc4a in FX::TnFXAppEventLoop::run() (this=0x84c0684)
    at TnFOX/src/TnFXApp.cxx:489
#18 0x08127e85 in Tn::TComponentI::run() (this=0x84c067c)
    at src/TComponent.cxx:135
#19 0x082a3aa8 in FX::FXThreadPrivate::run(FX::FXThread*) (t=0x84c068c)
    at TnFOX/src/FXThread.cxx:1371
#20 0x082a3638 in start_thread (t=0x84c068c) at TnFOX/src/FXThread.cxx:1260
#21 0x4011c332 in start_thread () from /lib/tls/libpthread.so.0
#22 0x420de867 in clone () from /lib/tls/libc.so.6

I reimplement global operator new and delete plus define namespace local 
versions of malloc, calloc, realloc and free which use an alternative dynamic 
memory allocator. In theory, the system allocator should never be called at all 
but unfortunately it would seem libstdc++ doesn't always use operator new - from 
a search it does seem to use malloc (which would be ::malloc which would cause a 
problem). To test if it's the SGI STL memory cache, I defined GLIBCXX_FORCE_NEW 
in the environment but there was no effect. Given the SGI STL works the same in 
non optimised code and it works there fine, I can't see it being this cause.

As is obvious from the above, when optimisation is on GCC is calling the wrong 
memory allocator which when freed later (above) causes a segfault (the assert 
sanity check stops just beforehand). I am at my wits end - do you guys know what 
could be causing this - where should I investigate first? What should I do next?

FYI the MSVC build on Windows runs just dandy. I'm recompiling with Intel C++ v8 
as I type this and I'll make an addendum when I know the result.

Cheers,
Niall

-- 
           Summary: Enabling optimisation causes segfault
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: s_gccbugzilla at nedprod dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16027