#include <locale>
#include <iostream>
Simple programs like the one below fail with segmentation faults. It happens
with locales and streams, and probably others, when they are created statically.
g++ is from a recent CVS.
static const std::locale l;
//static std::ostream& o = std::cerr;
int main(const int,
const char * const * const)
{
return 0;
}
$ uname -a
CYGWIN_NT-5.1 McKelvey-PC 1.5.12(0.116/4/2) 2004-11-10 08:34 i686 unknown unknow
n Cygwin
Reading specs from /usr/local/lib/gcc/i686-pc-cygwin/4.0.0/specs
Configured with: /home/User/cvsroot/gcc/configure --verbose --enable-threads
--with-gnu-as --with-gnu-ld --disable-nls --enable-languages=c++
Thread model: posix
gcc version 4.0.0 20041209 (experimental)
/usr/local/libexec/gcc/i686-pc-cygwin/4.0.0/cc1plus.exe -E -quiet -v
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/../include/w32api -idirafter
/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../../include/w32api test.cc
-mtune=pentiumpro -fpch-preprocess -o test.ii
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../include/c++/4.0.0
/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../include/c++/4.0.0/i686-pc-cygwin
/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/include
/usr/include
/usr/lib/../include/w32api
End of search list.
/usr/local/libexec/gcc/i686-pc-cygwin/4.0.0/cc1plus.exe -fpreprocessed test.ii
-quiet -dumpbase test.cc -mtune=pentiumpro -auxbase test -version -o test.s
GNU C++ version 4.0.0 20041209 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.0.0 20041209 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
as -o test.o test.s
/usr/local/libexec/gcc/i686-pc-cygwin/4.0.0/collect2.exe -Bdynamic
--dll-search-prefix=cyg -o test.exe /lib/crt0.o
-L/usr/local/lib/gcc/i686-pc-cygwin/4.0.0
-L/usr/local/lib/gcc/i686-pc-cygwin/4.0.0/../../.. test.o -lstdc++ -lgcc
-lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
This is what gdb reports just prior to the fault:
Breakpoint 2, 0x00405ec0 in pthread_getspecific ()
(gdb) bt
#0 0x00405ec0 in pthread_getspecific ()
#1 0x0040528d in _Unwind_SjLj_Register (fc=0x22eee8)
at /home/User/cvsroot/gcc/gcc/gthr-posix.h:496
#2 0x00430f26 in std::ios_base::Init::Init() ()
#3 0x004010a9 in __static_initialization_and_destruction_0(int, int) ()
#4 0x00401111 in _GLOBAL__I_main ()
#5 0x61004918 in getprogname () from /usr/bin/cygwin1.dll
#6 0x61118080 in cygwin1!__cygwin_user_data ()
#7 0x0022ef78 in ?? ()
#8 0x610064fb in cygwin1!__main () from /usr/bin/cygwin1.dll
Previous frame inner to this frame (corrupt stack?)
(gdb)
$ less test.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=00405EC5
eax=0000000B ebx=00438ED4 ecx=77E75A91 edx=0043A168 esi=00438ED0 edi=61118100
ebp=0022EE78 esp=0022EE6D program=C:\cygwin\home\User\PD\test.exe, pid 4024, thr
ead main
cs=001B ds=0023 es=0023 fs=0038 gs=0000 ss=0023
Stack trace:
Frame Function Args
6 [main] test 4024 handle_exceptions: Error while dumping state (probably
corrupted stack)
test.exe.stackdump (END)
The gdb is the one delivered with cygwin (along with gcc 3.4.1), so it may not
be entirely trustworthy for 4.0.
--
Summary: Segmentation Violation in pthread_getspecific
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mckelvey at maskull dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997
