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 ?
------ 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 ...
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
Any update on this?
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. greetings, Florian La Roche