From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30734 invoked by alias); 29 Aug 2005 19:47:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 30719 invoked by uid 48); 29 Aug 2005 19:47:46 -0000 Date: Mon, 29 Aug 2005 19:55:00 -0000 From: "mmarcus at emarcus dot org" To: gcc-bugs@gcc.gnu.org Message-ID: <20050829194742.23628.mmarcus@emarcus.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/23628] New: Typeinfo comparison code easily breaks shared libs X-Bugzilla-Reason: CC X-SW-Source: 2005-08/txt/msg03357.txt.bz2 List-Id: There is a problem in GCC's typeinfo comparison code where it just compares the address of the symbol, not what the symbol points at. Hence if the linker chooses one typeinfo instance in one binary and another in another binary, even though they are the same typeinfo it returns different results. This means you must be very, very careful to ensure the typeinfos for the symbols which get compared must be default visibility in ALL compilation units if and ONLY if the RTTI "lives" in different shared libraries. As you might guess, this can get tricky to get right! We were fortunate that in one of the boost::signals test executables, this leads to a repeatable crash (boost_any_bridge fails to detect that two types are the same, because of an erroneous type info comparison). It is much worse in some other situations. I have seen silent failures (such as the "type" of a standard exception being changed between where it is thrown and where it is caught). The problem was obscured by a time by the fact that, despite claims to the contrary in the documentation, it seems that the symbols are not being made visible in the "hosting" executable by default. As a result we have two separate copies of the typeinfo. -- Summary: Typeinfo comparison code easily breaks shared libs Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmarcus at emarcus dot org CC: gcc-bugs at gcc dot gnu dot org,gdr at integrable- solutions dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628