Bug 88625

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
problem.


------- 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?
Thanks.


------- 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*
compat-libstdc++-2.10.0-1
libstdc++-2.95.3-0.81


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

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:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=37933

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:
   
http://www10.software.ibm.com/developerworks/opensource/linux390/special_oco_rh_
2.4.shtml#rh7.2_249-38

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:

http://oss.software.ibm.com/developerworks/opensource/linux390/current2_4_19-
may2002.shtml


------- 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.
Thanks.


------- 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
response.

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