Bug 61138 - Programs compiled with recently updated libstdc++3 gcc3 (RH 3.0.4) segfault
Programs compiled with recently updated libstdc++3 gcc3 (RH 3.0.4) segfault
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: libstdc++ (Show other bugs)
7.2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-14 00:03 EST by Alaeddin A. Aydiner
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-12-15 14:34:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alaeddin A. Aydiner 2002-03-14 00:03:34 EST
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 14:34:37 EST
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.