Bug 186410 - infinite recursion in btowc() function (libstdc++.so.5)
infinite recursion in btowc() function (libstdc++.so.5)
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: compat-gcc-32 (Show other bugs)
5
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-23 08:52 EST by Pavel Dobry
Modified: 2014-07-12 05:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: 3.2.3-56.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-13 05:41:56 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 Pavel Dobry 2006-03-23 08:52:55 EST
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(&timestamp); 
	ta = localtime(&timestamp);
	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;
}
Comment 1 Jakub Jelinek 2006-03-29 11:42:35 EST
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
Comment 2 P H 2006-05-23 17:20:42 EDT
Any sign of this been fixed.
FC5 is now updated to glibc-2.4-8 and still not working.
Comment 3 Sergey D 2006-06-06 14:01:11 EDT
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!
Comment 4 P H 2006-07-10 18:34:19 EDT
Over 3 months since this BUG was submitted here and it still hasn't been fixed.
Comment 5 Need Real Name 2006-09-13 10:52:49 EDT
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
Comment 6 Jakub Jelinek 2006-09-18 14:27:23 EDT
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.
Comment 7 Sergey D 2006-09-30 16:12:15 EDT
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?
Comment 8 Pavel Dobry 2006-10-06 09:57:11 EDT
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.
Comment 9 Jakub Jelinek 2006-12-13 05:41:56 EST
Forgot to close this, the updates are out for more than 2 months already.

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