Boost C++ Libraries: Ticket #754: boost::any - typeid comparison across shared boundaries

kulik — Sat, 06 Jan 2007 10:49:06 GMT

Logged In: YES
user_id=1620918
Originator: YES
This is IMO a really critical bug and can be very easily solved. Many applications won't work if they use some kind of module mechanism with shared objects. I spend many hours smashing my head till I realised what's causing it.

alnsn — Tue, 16 Jan 2007 20:38:29 GMT

Logged In: YES
user_id=369903
Originator: NO
Since it's a bug in C++ implementation, I don't see why I should replace ASAP a portion of good C++ with non-portable code. I would rather suggest you first check if this bug is already in a queue of your C++ vendor and post a link here.
In a meantime, I will study boost.python workaround and other libraries. There ought to be portable type_info somewhere. Boost should not have multiple clones of this functionality. This is especially important for non-portable code.

kulik — Tue, 16 Jan 2007 20:58:10 GMT

Logged In: YES
user_id=1620918
Originator: YES
I know it's kinda a gcc specific problem, but if you watch Visual C++ output, it's technically doing the same, string comparison of the type representation. Gcc tries to be faster by comparing memory adressess of structures characterizing the types, these structures are unfortunately linked separately into each boundary, thus causing this problem when using boost::any across the boundary.
official gcc bug entry:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628
There are various references of the problem on gcc.gnu.org mailing list:
http://gcc.gnu.org/ml/gcc/2002-05/msg01970.html
http://gcc.gnu.org/ml/gcc/2003-10/msg01360.html (unanswered)
However this bug prevails from somewhere around gcc-3 on. Before gcc-3 textual comparison was made to compare types (this is how many compilers do it nowadays).
PS: The same problem also exists for dynamic_cast, type comparison fails there too and casts are invalid across shared boundaries.
(shared boundary - for example .dll or .so, the problem surfaces when I boost::any_cast something from application in code from the shared object or vice versa)
I apologise for priority bumping this bug, it has really been irritating me for a long time.
PS: dynamically loading shared objects as RTLD_GLOBAL seems to solve this bug, but I consider this a workaround.

owner, status changed; severity set

nasonov — Wed, 29 Aug 2007 09:08:19 GMT

owner changed from alnsn to nasonov
status assigned → new
severity → Problem

component, description changed

Marshall Clow — Wed, 29 Aug 2007 14:28:14 GMT

component None → any
description modified (diff)

staffan.spam at gimaker se — Sun, 16 Dec 2007 21:06:23 GMT

I was bit my this bug as well, and it really wasn't fun to track down.

Using RTLD_GLOBAL isn't possible when using libltdl to load the DSO, since lt_dlopenext() doesn't expose a way to control the flags used with dlopen.

The only fix for this is for us to maintain a patched version of any.hpp, that has the above workaround implemented - which seems like a hopelessly fragile solution.

It doesn't seem like the GCC crowd will *ever* fix this, so can you please consider implementing a workaround for it in Boost?

Mike Dickey — Mon, 11 Feb 2008 23:10:32 GMT

<banging head against the wall>Just for the record: I lost a day and a half to this bug too... until I was finally able to figure out what seemed to be happening and prove to myself that it wasn't my code that was at fault. Tough one too, because it works fine on some platforms (Windows, OSX, etc.) but not others (i.e. Linux). I agree that this is a really nasty bug b/c it makes Boost's behavior non-deterministic across platforms, which I thought was part of the whole point... </banging head against the wall>

ulit at eikon dot com — Wed, 25 Feb 2009 10:59:09 GMT

Same here as found by Mike and staffan: painful and long search why boost::any didn't work across library boundaries.

When the patch above is not acceptable: please consider an additional cast function (e.g. "any_cast_by_name") which does the type comparision based on strings.

anonymous — Sat, 06 Jun 2009 17:38:57 GMT

Replying to staffan.spam at gimaker se:

I was bit my this bug as well, and it really wasn't fun to track down.

Using RTLD_GLOBAL isn't possible when using libltdl to load the DSO, since lt_dlopenext() doesn't expose a way to control the flags used with dlopen.

libltdl always uses RTLD_GLOBAL, assuming RTLD_GLOBAL is defined for your platform. See libltdl/ltdl.c in libtool.

status, resolution changed

nasonov — Sun, 13 Sep 2009 13:16:30 GMT

status new → closed
resolution None → fixed

(In [56168]) Fix #754 (boost::any - typeid comparison across shared boundaries).