Description of problem: Function btowc() in library libstdc++.so.5 contains an infinite recursion. See disassembly, address 0x001b00da: [Switching to Thread -1292805216 (LWP 6559)] 0x001b00cc in btowc (__c=32) at /usr/include/wchar.h:330 warning: Source file is more recent than executable. 330 { return (__builtin_constant_p (__c) && __c >= '\0' && __c <= '\x7f' Current language: auto; currently c++ (gdb) disas Dump of assembler code for function btowc: 0x001b00c0 <btowc+0>: push %ebp 0x001b00c1 <btowc+1>: mov %esp,%ebp 0x001b00c3 <btowc+3>: sub $0x18,%esp 0x001b00c6 <btowc+6>: mov %ebx,0xfffffffc(%ebp) 0x001b00c9 <btowc+9>: mov 0x8(%ebp),%eax 0x001b00cc <btowc+12>: call 0x1600f2 <__i686.get_pc_thunk.bx> 0x001b00d1 <btowc+17>: add $0x242f3,%ebx 0x001b00d7 <btowc+23>: mov %eax,(%esp) 0x001b00da <btowc+26>: call 0x1b00c0 <btowc> 0x001b00df <btowc+31>: mov 0xfffffffc(%ebp),%ebx 0x001b00e2 <btowc+34>: mov %ebp,%esp 0x001b00e4 <btowc+36>: pop %ebp 0x001b00e5 <btowc+37>: ret 0x001b00e6 <btowc+38>: inc %edx 0x001b00e7 <btowc+39>: je 0x1b00f1 <btowc+49> 0x001b00e9 <btowc+41>: mov %eax,(%esp) 0x001b00ec <btowc+44>: call 0x15fbb0 0x001b00f1 <btowc+49>: mov %eax,(%esp) 0x001b00f4 <btowc+52>: call 0x15e080 End of assembler dump. (gdb) Symbol btowc is from libstdc++.so.5 library (from compat-libstdc++-33 RPM package): (gdb) info sharedlibrary From To Syms Read Shared Object Library 0x002db820 0x002f01df Yes /lib/ld-linux.so.2 0x00473510 0x0047bdb4 Yes /lib/libpthread.so.0 0x0045b770 0x00466a44 Yes /usr/lib/libz.so.1 0x00445b10 0x00446bc4 Yes /lib/libuuid.so.1 0x04b4a7c0 0x04b4de44 Yes /lib/libcrypt.so.1 0x00113410 0x0011e2f4 Yes /lib/libresolv.so.2 0x0042dc40 0x0042eb14 Yes /lib/libdl.so.2 0x0015ff50 0x001bb620 Yes /usr/lib/libstdc++.so.5 0x001ea360 0x00204dc4 Yes /lib/libm.so.6 0x0098a7d0 0x00991fc4 Yes /lib/libgcc_s.so.1 0x0030d5f0 0x003fa9a8 Yes /lib/libc.so.6 No zend/ZendExtensionManager_TS.so No zend/Optimizer_TS/php-4.3.x/ZendOptimizer.so 0x00742b20 0x00748fd4 Yes /lib/libnss_files.so.2 0x00285cb0 0x00289a74 Yes /lib/librt.so.1 (gdb) Version-Release number of selected component (if applicable): Fedora Core release 4.92 (Pre-FC5) Legacy Software Support packages: compat-gcc-32-3.2.3-55.fc5.src.rpm compat-gcc-32-debuginfo-3.2.3-55.fc5.i386.rpm compat-libstdc++-33 How reproducible: Compile example in RH9 or FC1. Output binary file depends on libstdc++.so.5 library. Run application on FC5 test3 or FC5. If you compile example in FC5, output binary file will depend on libstdc++.so.6 and will use btowc symbol from libc.so.6. Actual results: Application will crash on stack overflow due to infinite recursion in function btowc(). Expected results: Application will not crash. Compat-lbstdc++-33 package will be truly compatible. Example: void test_local_date() { time_t timestamp; struct tm *ta; time(×tamp); ta = localtime(×tamp); std::locale *loc = new std::locale("cs"); std::wstring format = "%x"; std::wostringstream wstr; std::use_facet<std::time_put<wchar_t> >(*loc).put(wstr, wstr, wstr.fill(), ta, format.data(), format.data() + format.length()); delete loc; }
This was actually a bug in glibc headers, should be fixed in rawhide glibc-2.4-5. This will be fixed in FC5 when: a) that fix is backported to FC5 glibc b) compat-gcc-32 is rebuilt
Any sign of this been fixed. FC5 is now updated to glibc-2.4-8 and still not working.
We have a test environment installed with several machines running FC5 and now we are planning to deploy Kerio Mailserver for the test. It is a proved fact that Kerio software is affected by this particular bug in libstdc++.so.5 and we will appreciate if it could be possible to rectify it asap by releasing an updated compat-libstdc++-33 package. As far as we understand from above the cause of the problem and the way out were already determined. Thanks in advance!
Over 3 months since this BUG was submitted here and it still hasn't been fixed.
I am having the same issue. We are running FC5 Also and are trying to deply Kerio Mail Server and this big is the only thing preventing that. It has now been over 6 months since the bug was identified with no fix. Does anyone have any updats as to when this will be addressed? Thanks
https://www.redhat.com/archives/fedora-test-list/2006-September/msg00450.html Anyone actively using these please give them a shot and report here (even success reports would be useful), thanks. If nothing wrong is reported, it will be pushed as official FC5 update this week.
Jakub, I have installed the test update today and it looks to be working fine, at least in respect to the issue related with Kerio products. No more crashes. Are there any other issues identified with this update since as I can see it is still in the "test" mode and not released officially?
Test update is working fine. No problems were detected. Applications compiled in RH9 and FC1 can run with testing compat-libstdc++ package in FC5 without problem.
Forgot to close this, the updates are out for more than 2 months already.