Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 88625 - LTC2407-bug in libstdc++ in RH7.2 s/390
Summary: LTC2407-bug in libstdc++ in RH7.2 s/390
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libstdc++
Version: 7.2
Hardware: s390
OS: Linux
Target Milestone: ---
Assignee: Florian La Roche
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-11 15:49 UTC by IBM Bug Proxy
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-08-19 08:50:57 UTC

Attachments (Terms of Use)

Description IBM Bug Proxy 2003-04-11 15:49:32 UTC
Please fill in each of the sections below.

Hardware Environment:  s/390 

Software Environment: RedHat Linux 7.2 for s/390 + updates

Steps to Reproduce:
1. Create a test program that creates a certain number of threads (20+ to
recreate stress test situation). Each thread is linked to the same function.
That function creates a C++ object and inside a try block throws it and tries to
catch it (in the catch block).
2. Either right at the beginning or after some time, 2 or more threads will
throw the C++ object at the same time and that object will get caught by the
other thread. 
3. You can use a sleep(1) statement - to allow the threads to get a share of the
CPU - or not, the problem still shows up. I used a for loop that makes each
thread throw the object 1000 times.

Here some cut and paste:
without the 'sleep(1)'
throwing MyObject 0 in thread 0
throwing MyObject 1 in thread 1
catching MyObject 0 in thread 0
throwing MyObject 0 in thread 0
catching MyObject 0 in thread 1
catching MyObject 0 in thread 0

with the 'sleep(1)':
throwing MyObject 3 in thread 3
throwing MyObject 2 in thread 1
catching MyObject 2 in thread 3
throwing MyObject 0 in thread 0
catching MyObject 0 in thread 0
throwing MyObject 6 in thread 5
catching MyObject 6 in thread 5
throwing MyObject 5 in thread 6
catching MyObject 5 in thread 6
...if you wandered where is MyObject 3 is caught? here it is:
catching MyObject 3 in thread 1

Actual Results: Objects aren't caught by the thread they were throw from.

Expected Results: Object get caught by the thread they were throw from.

Additional Information: In our real life stress test, replacing the
libstdc++-3-libc6.1-2-2.10.0.so file by the one from SuSE SLES7 s/390 solves the

------- Additional Comment #1 From Khoa D. Huynh 2003-04-04 18:02 -------

Florence - do you think problem is the same as Bug 2336 ?  I think your
libstdc++ version is later than the one in Bug 2336.

By the way, can you specify the "updates" that you have applied to your system?

------- Additional Comment #2 From Florence Adam 2003-04-07 06:29 -------

This is the RPM DB output. Rh7.2 for s/390 is still on 2.95 so I don't think the
problem is related to bug 2336 (which is for 2.96).

$ rpm -qa | grep libstdc*

$ rpm -qf /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so

The 'updates' I mention are those available internally on the LTC's server for
RH7.2 s390 (in the RedHat/updates directory).

I am not sure why the compat-libstdc++ is installed and what difference it makes
with libstdc++-2.95.3-0.81 in terms of level.

Thanks, Flo

------- Additional Comment #3 From Khoa D. Huynh 2003-04-07 18:17 -------

Florence - I think there have been several bug reports related to this area
(throwing and catching exceptions/objects) using libstdc++.  Various
problems were reported in Bug 37933 in Red Hat Bugzilla:


Problems were reported against gcc-2.95 and some even against gcc-2.96.
Red Hat told us that these problems have already been fixed, but it
is not clear exactly since which versions they have been fixed.

I'd like to ask if you can try the following:

1. Make sure that EVERYTHING is compiled using the SAME level of toolchain
   (gcc, libstdc++, etc.).  Also make sure that EVERYTHING is run on that
   SAME level of toolchain.  Binary compatibility is NOT guaranteed across
   different levels, and certainly, NOT across different distributions.

2. Make sure your system have the correct OCO modules:

3. If bug still exists, please upgrade to a more recent version of toolchain.
   For example, you can try the gcc-3.2 toolchain available in the "May 2002
   stream" on developerWorks:


------- Additional Comment #4 From Florence Adam 2003-04-08 09:50 -------

Khoa, Thanks for those last comments.
My situation is such as I need to be able to support both SuSE SLES 7 s/390 and
RH7.2 s/390. The build environment cannot be changed anymore at this point in
time. As well, we support those distributions 'out of the box' or with
relatively easy to install updates. The last link you gave me is interesting but
means moving from 2.4.9 to 2.9.17 upgrading other things in the mean time, which
means it could be a tricky upgrade for customers. As well the application needs
to run in a similar environment to the one it was built in (and tested in) for
expansion reasons and serviceability. As well, We do have up to date OCO drivers
for Rh7.2 s/390.
It seems very unclear as to when and where this fix is and why push an upgrade
from 2.95 to 3.2 when the later is not backwards compatible and means a
different environment to which the original application (in our case) was built.
Can you see any other solution?
Cheers,  Flo

------- Additional Comment #5 From Khoa D. Huynh 2003-04-08 17:25 -------

Florence - I understand your situation.  I have just one question: would you
encounter this bug if everything was compiled *and* run on the SAME level 
of toolchain and on the SAME distribution ?  Please clarify this for me.

------- Additional Comment #6 From Florence Adam 2003-04-09 06:48 -------

Khoa, This is a question I cannot answer really because we do not have the
resources and time to check this. Anyhow, the little threading example I
outlined in the original report _was_ compiled and ran on the same toolchain
(RedHat 7.2 s/390), and it showed the same problem as our application. But the
same example compiled and ran on SuSE SLES 7 s/390 didn't show the problem.
So I cannot say a straight 'yes' to answer your question because of that, I
think the problem might still be there and unless a fix is provided as an update
to the 'out-of-the-box' distribution I cannot spare time at this point in our
cycle to verify this.
Thanks, Flo

------- Additional Comment #7 From Khoa D. Huynh 2003-04-11 03:50 -------

Greg/Glen - please submit this to Red Hat as soon as possible.  Thanks.

I'll also try to contact Frank Hirtz at Red Hat to see if we get a faster

Florence - can you attach your test program to this bug report ?

Comment 1 IBM Bug Proxy 2003-05-13 22:16:15 UTC
------ Additional Comment #16 From Ulrich Weigand  2003-05-09 12:37 -------

Note that libstdc++ exception handling is only thread-safe if 
GCC was configured using the --enable-threads=posix option.

In more recent releases, the s390 target automatically defaults
to this setting, but the 2.95.3 release would not; you have to
explicitly specify the option.

I know that SuSE does have this option in their gcc spec file,
but I haven't looked at the Red Hat one yet ...

Comment 2 IBM Bug Proxy 2003-05-28 16:37:28 UTC
Just to be sure: 
You all know that in the worst case all Redhat C++ programms and libraries that 
use pthreads and exception handling have to be recompiled with the fixed 

Comment 3 IBM Bug Proxy 2003-06-19 15:36:37 UTC
Any update on this?

Comment 4 Florian La Roche 2003-08-19 08:50:57 UTC
We don't plan to re-compile all C++ code with fixed exception handling, but
will promote the upcoming RHEL3 release for mainframe and work on any bug-reports
coming in for that.


Florian La Roche

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