Re: other/6602: GCC/Linux shared lib + EH bug example

Re: other/6602: GCC/Linux shared lib + EH bug example

[Ralf W. Grosse-Kunstleve]

The following reply was made to PR other/6602; it has been noted by GNATS.

From: "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov>
To: gcc-gnats@gcc.gnu.org
Cc: loewis@informatik.hu-berlin.de, rwgk@boa.lbl.gov
Subject: Re: other/6602: GCC/Linux shared lib + EH bug example
Date: Wed, 8 May 2002 15:32:26 -0700 (PDT)

 I updated the Makefile in gcc_dl_eh.tar.gz to include the target
 "sun_gcc" and I ran the test on this platform:
 
 SunOS mcfsrv 5.8 Generic_108528-08 sun4u sparc SUNW,Ultra-Enterprise
 gcc 3.0.4
 
 There is no problem with the exception handling on this platform
 (i.e. there are 8 out of 8 "success").
 
 The updated tar file is at the old location:
     http://cci.lbl.gov/~rwgk/tmp/gcc_dl_eh.tar.gz
 
 Ralf

Re: other/6602: GCC/Linux shared lib + EH bug example

[Ralf W. Grosse-Kunstleve]

The following reply was made to PR other/6602; it has been noted by GNATS.

From: "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov>
To: gcc-gnats@gcc.gnu.org
Cc: david.abrahams@rcn.com, rwgk@boa.lbl.gov
Subject: Re: other/6602: GCC/Linux shared lib + EH bug example
Date: Thu, 9 May 2002 12:11:17 -0700 (PDT)

 Another update at http://cci.lbl.gov/~rwgk/tmp/gcc_dl_eh.tar.gz
 
 The Makefile now includes support for MAC OS 10.1 cc (== gcc 2.95.2)
 using dlcompat.
 All tests succeed on this platform.
 So far gcc 3.0.4/Linux is the only combination that fails.
 
 Ralf

Re: other/6602: GCC/Linux shared lib + EH bug example

[Ralf W. Grosse-Kunstleve]

The following reply was made to PR other/6602; it has been noted by GNATS.

From: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com>
To: c++-sig@python.org, gcc-gnats@gcc.gnu.org
Cc: loewis@informatik.hu-berlin.de
Subject: Re: other/6602: GCC/Linux shared lib + EH bug example
Date: Wed, 8 May 2002 11:23:02 -0700 (PDT)

 Martin v. Loewis wrote:
 > Looking at your example gcc_dl_eh: Can you please try to not define
 > the worker_error dtor inline? I.e. implement it in libcore.cpp
 > instead; I'd be curious whether this changes anything.
 
 It does not change the outcome. See attached.
 Thanks,
         Ralf
 
 % make
 gcc -g -c master.c
 gcc -o master master.o -ldl
 g++ -g -c ext1.cpp
 g++ -g -c libcore.cpp
 g++ -shared -Wl,-E -o libcore.so libcore.o
 g++ -shared -Wl,-E -o ext1.so ext1.o libcore.so
 g++ -g -c ext2.cpp
 g++ -shared -Wl,-E -o ext2.so ext2.o libcore.so
 *********************************************************
 LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master G 1
 dlopen flag: RTLD_GLOBAL
 init_ext1
 init_ext2
 run1
   mycore::dispatcher
     ext1::worker
       now throwing worker_error()
     success catching worker_error
 run2
   mycore::dispatcher
     ext2::worker
       now throwing worker_error()
     success catching worker_error
 
 *********************************************************
 LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master G 2
 dlopen flag: RTLD_GLOBAL
 init_ext2
 init_ext1
 run1
   mycore::dispatcher
     ext1::worker
       now throwing worker_error()
     success catching worker_error
 run2
   mycore::dispatcher
     ext2::worker
       now throwing worker_error()
     success catching worker_error
 
 *********************************************************
 LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master L 1
 dlopen flag: RTLD_LOCAL
 init_ext1
 init_ext2
 run1
   mycore::dispatcher
     ext1::worker
       now throwing worker_error()
     success catching worker_error
 run2
   mycore::dispatcher
     ext2::worker
       now throwing worker_error()
     #################################
     #                               #
     # FAILURE catching worker_error #
     #                               #
     #################################
 
 *********************************************************
 LD_LIBRARY_PATH=.:/usr/local_cci/gcc-3.0.4/lib master L 2
 dlopen flag: RTLD_LOCAL
 init_ext2
 init_ext1
 run1
   mycore::dispatcher
     ext1::worker
       now throwing worker_error()
     #################################
     #                               #
     # FAILURE catching worker_error #
     #                               #
     #################################
 run2
   mycore::dispatcher
     ext2::worker
       now throwing worker_error()
     success catching worker_error
 
 
 __________________________________________________
 Do You Yahoo!?
 Yahoo! Health - your guide to health and wellness
 http://health.yahoo.com

Re: other/6602: GCC/Linux shared lib + EH bug example

[Ralf W. Grosse-Kunstleve]

The following reply was made to PR other/6602; it has been noted by GNATS.

From: "Ralf W. Grosse-Kunstleve" <rwgk@cci.lbl.gov>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, rwgk@boa.lbl.gov
Cc:  
Subject: Re: other/6602: GCC/Linux shared lib + EH bug example
Date: Tue, 7 May 2002 22:46:46 -0700 (PDT)

 Sorry, accidentally I did not attach the gcc_dl_eh.tar.gz file
 as promised. You can find the file at this URL:
 http://cci.lbl.gov/~rwgk/tmp/gcc_dl_eh.tar.gz
 Ralf

other/6602: GCC/Linux shared lib + EH bug example

[rwgk]

>Number:         6602
>Category:       other
>Synopsis:       GCC/Linux shared lib + EH bug example
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 07 19:26:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     rwgk@cci.lbl.gov
>Release:        gcc 3.0.4
>Organization:
>Environment:
RedHat 7.1 on Intel
>Description:
I have reduced an exception-handling problem
mentioned here

http://mail.python.org/pipermail/c++-sig/2002-May/001021.html

This is clearly a GCC/Linux interaction problem, not a Python bug. However, it does have a serious impact on anyone writing Python extension modules with g++ on Linux.
>How-To-Repeat:
Get the attached. Then:

gunzip -c gcc_dl_eh.tar.gz | tar xvf -
cd gcc_dl_eh
more 0README
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: