Bug 61138 - Programs compiled with recently updated libstdc++3 gcc3 (RH 3.0.4) segfault
Summary: Programs compiled with recently updated libstdc++3 gcc3 (RH 3.0.4) segfault
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libstdc++
Version: 7.2
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-03-14 05:03 UTC by Alaeddin A. Aydiner
Modified: 2008-05-01 15:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-12-15 19:34:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Alaeddin A. Aydiner 2002-03-14 05:03:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.0.3 (X11; Linux i686; U;) Gecko/20020205

Description of problem:
Almost all the code I could successfully compile using gcc3/libstdc++3
segfault now. This happened after I installed the zlib-related updates:

[~][3131] >rpm -q zlib zlib-devel gcc3 gcc3-c++ libstdc++3 libstdc++3 binutils
zlib-1.1.3-25.7
zlib-devel-1.1.3-25.7
gcc3-3.0.4-1
gcc3-c++-3.0.4-1
libstdc++3-3.0.4-1
libstdc++3-3.0.4-1
binutils-2.11.90.0.8-12

In each case, the backtrace is very similar and seems to be a libc++3-related
problem.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
I am trying to find a small piece of code that demonstrates the problem. I
haven't yet been able to isolate where it segfaults. The segfault is very
immediate, i.e. trying to write something to stdout
and flushing it does not work even though I put the statement right after main():
int main() { std::cout << "Cannot even see this before segfault!\n" <<
std::flush; ... }

I hope the backtrace will help you. It is weird because the code has nothing to
do with wide characters. The numerical codes that I unfortunately cannot post
here were compiled with "g++3 -fno-exceptions -fno-rtti -fstrict-aliasing" and
all produce similar backtraces.

Thanks.

Additional info:

#0  __wcslen (s=0x0) at wcslen.c:30
#1  0x0809e6c7 in std::numpunct<wchar_t>::_M_initialize_numpunct(int*) (
    this=0x80f4b10)
    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/char_traits.h:227
#2  0x0809b397 in std::locale::_Impl::_Impl(std::string, unsigned) (
    this=0x80f4528, __str=0xbfffe100, __refs=2)
    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/locale_facets.h:850
#3  0x08096ff1 in std::locale::classic() ()
    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/stl_alloc.h:571
#4  0x08096675 in std::locale::locale() (this=0x80eeb90)
    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/localefwd.h:324
#5  0x080af7b3 in std::basic_streambuf<char, std::char_traits<char>
>::basic_streambuf() (this=0x80eeb60)
    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/std_streambuf.h:382
#6  0x080b1ec8 in std::basic_filebuf<char, std::char_traits<char>
>::basic_filebuf(_IO_FILE*, std::_Ios_Openmode, int) (this=0x80eeb60,
__f=0x80dd120, 
    __mode=16, __s=0)#7  0x08095918 in std::ios_base::Init::_S_ios_create(bool)
(__sync=1)
    at ../../../../libstdc++-v3/libsupc++/new:86
#8  0x08095ee9 in std::ios_base::Init::Init() (this=0x80ee8dc)
    at ../../../../libstdc++-v3/src/ios.cc:203
#9  0x0804a1e9 in __static_initialization_and_destruction_0(int, int) (
    __initialize_p=1, __priority=65535)
    at /usr/include/g++-v3/bits/std_iostream.h:57
#10 0x0804a23a in _GLOBAL__I__ZN5SDFFT15InvalidArgumentEPKcRKm ()
    at /usr/include/g++-v3/bits/locale_facets.tcc:75
#11 0x08094b6b in __do_global_ctors_aux ()
    at ../../../../libstdc++-v3/libsupc++/eh_aux_runtime.cc:39
#12 0x080480ca in _init ()
#13 0x0804d852 in __libc_start_main (main=0x8048820 <main>, argc=1, 
    ubp_av=0xbfffe294, init=0x80480b4 <_init>, fini=0x80c7c80 <_fini>, 
    rtld_fini=0, stack_end=0xbfffe28c) at ../sysdeps/generic/libc-start.c:122

    at
/usr/src/build/75527-i386/BUILD/gcc-3.0.4-20020221/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v3/include/bits/fstream.tcc:122

Comment 1 Alan Cox 2002-12-15 19:34:37 UTC
gcc 3.0.4 was an experimental release so won't be getting updates. 3.2 seems fine



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