From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7708 invoked by alias); 13 Jan 2003 12:16:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 7678 invoked by uid 71); 13 Jan 2003 12:16:02 -0000 Resent-Date: 13 Jan 2003 12:16:02 -0000 Resent-Message-ID: <20030113121602.7677.qmail@sources.redhat.com> Resent-From: gcc-gnats@gcc.gnu.org (GNATS Filer) Resent-Cc: gcc-prs@gcc.gnu.org, gcc-bugs@gcc.gnu.org Resent-Reply-To: gcc-gnats@gcc.gnu.org, ptsekov@gmx.net Received: (qmail 6402 invoked by uid 61); 13 Jan 2003 12:08:09 -0000 Message-Id: <20030113120809.6401.qmail@sources.redhat.com> Date: Mon, 13 Jan 2003 12:16:00 -0000 From: ptsekov@gmx.net Reply-To: ptsekov@gmx.net To: gcc-gnats@gcc.gnu.org X-Send-Pr-Version: gnatsweb-2.9.3 (1.1.1.1.2.31) Subject: c++/9291: Exceptions thrown from a shared library are not catched in the main program on Solaris9/SPARC X-SW-Source: 2003-01/txt/msg00804.txt.bz2 List-Id: >Number: 9291 >Category: c++ >Synopsis: Exceptions thrown from a shared library are not catched in the main program on Solaris9/SPARC >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Jan 13 04:16:01 PST 2003 >Closed-Date: >Last-Modified: >Originator: Pavel Tsekov >Release: gcc-3.2 >Organization: >Environment: $ uname -s -r -v -p -i SunOS 5.9 Generic_112233-01 sparc SUNW,SPARCstation-20 $ gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.2/specs Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls Thread model: posix gcc version 3.2 >Description: I'm using libodbc++-0.2.2 (http://orcane.net/freeodbc++/) in an app which connects to a MySQL database. I found out that on Solaris 9 this app will repeatedly crash if the database is missing. I turned out that the exception thrown by libodbc++ is not propery caught and causes a coredump. Here is a stack trace from the mysql test program which accompanies libodbc++-0.2.2: (gdb) bt #0 0xef21cbe8 in _lwp_kill () from /usr/lib/libc.so.1 #1 0xef1cbb5c in raise () from /usr/lib/libc.so.1 #2 0xef1b56b0 in abort () from /usr/lib/libc.so.1 #3 0xef3d9abc in ?? () at dyn-string.c:70 from /usr/local/lib/libstdc++.so.5 #4 0xef3d9b0c in ?? () at dyn-string.c:70 from /usr/local/lib/libstdc++.so.5 #5 0xef3d9c80 in ?? () at dyn-string.c:70 from /usr/local/lib/libstdc++.so.5 #6 0xef645428 in _ZN4odbc12ErrorHandler16_checkErrorODBC3ElPvsRKSs ( this=, handleType=2, handle=0x2dcc0, ret=-1, what=@0xeffff8b0) at ../../libodbc++-0.2.2/src/errorhandler.cpp:188 #7 0xef655d10 in ?? () at ../../libodbc++-0.2.2/include/odbc++/types.h:714 from /home/ptsekov/src/libodbc++-0.2.2-obj/tests/../src/.libs/libodbc++-mt.so.4 #8 0xef623f48 in _ZN4odbc10Connection8_connectERKSs (this=, connectString=@0xeffffb70) at ../../libodbc++-0.2.2/src/connection.cpp:215 #9 0xef6223ac in _ZN4odbc13DriverManager13getConnectionERKSs ( connectString=@0xeffffb70) at ../../libodbc++-0.2.2/src/drivermanager.cpp:172 #10 0x17f1c in main (argc=2, argv=0xeffffbf4) at ../../libodbc++-0.2.2/tests/mysql.cpp:495 Now, if I build a static version of the library the above test case works as expected and reports an error instead of crashing. Here are the options I've passed to the configure script of libodbc++: ../libodbc++-0.2.2/configure --with-odbc --with-pic --enable-threads Please, let me know if you need further information. If required I can try to build a minimal test case if libodbc++ is not well suited for the task. I can also provide interested parties with precompiled binaries to avoid loosing time in figuring out how to build libodbc++. >How-To-Repeat: Build libodbc++-0.2.2 as a shared library and try to run the mysql test program on Solaris9/SPARC. >Fix: Build libodbc++-0.2.2 as a static library. >Release-Note: >Audit-Trail: >Unformatted: