• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Exceptions thrown from framework not caught in application [Workaround]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exceptions thrown from framework not caught in application [Workaround]


  • Subject: Re: Exceptions thrown from framework not caught in application [Workaround]
  • From: Andreas Grosam <email@hidden>
  • Date: Thu, 14 Sep 2006 17:18:03 +0200


On 14.09.2006, at 15:00, Andreas Grosam wrote:


On 14.09.2006, at 00:55, Steve Baxter wrote:

On 13 Sep 2006, at 22:54, Andreas Grosam wrote:

Unfortunately, i can confirm now, that this issue also happens with shared libraries, which comprise a legal application. I created the application in Xcode 2.4 on 10.4.7.

On 10.4.x, the application works correctly. On 10.3.9 it fails.

It is pretty much obvious that the dynamic linker on 10.3.9 is unable to merge several definitions of coalesced weak symbols. For RTTI this kind of symbol will be produced quite often - but not always, the alternative is to use undefined references.

More specifically, if a RTTI symbol (in this example for the class Error) is defined in more than one DSO like this:

000041c8 (__DATA,__const_coal) weak external __ZTI5Error

the dyld of 10.3.x fails to coalesce the definitions into a single one, and hence the ODR will be violated.


I failed also to find a workaround so far, like forcing to create the RTTI definition where the class ctor is defined, and subsequently *reference* to existing RTTI symbols instead creating new definitions in the calling DSO. However the compiler preferes to create new definitions anyway,

Eventually, I found a workaround, which works for shared libraries. (I would like to exclude plugins so far, since it is not clear how plugins share such facilities at all. But later.)


The idea is to avoid multible definitions of RTTI symbos in several DSOs. Notice, that during building of a certain DSO, the acyclic graph of needed objects must be known by the linker. This will be ensured through specifying to link against all shared libraries that contain the definitions to the referenced symbols.

If there is only one definition of the RTTI symbols in a set of DSOs in the fully linked application, the flaw in dyld in 10.3.9 wouldn't have an effect.

In order to ensure that only one definition of an RTTI symbol is generated for a set of DSOs comprising the acyclic linked graph of needed objects, it must be ensured that a so-called "trigger function" is defined for that class.

A trigger function is the first virtual member function which is declared non-pure and non-inline. If the compiler detects such a function, it defines the associated RTTI symbols in the same module where the trigger function is defined. Subsequent references to the RTTI symbols - even from outside the DSO where they are defined - will now use references instead of their own (weak coalesced) definitions.

For the trigger funciton, the class' dtor might be choosen for that purpose, although any other member function would do the trick as well. If you use a dummy function though, you need to ensure that this function will not be dead-stripped, and in turn the RTTI symbols as well (needs further investigation).

Notice also, that for each exported class a trigger function has to be defined. It is not sufficient, that this is defined in a base class only.


Say we have a class which is subject to be exported and which RTTI symbols will be referenced from within other DSOs:


// file Error.h
#define EXPORT __attribute__((visibility ("default")))

class EXPORT Error
{
public:
	Error(int e);

virtual ~Error(); // must be defined. Provides the "trigger function".
...
private:
int _e;
};



// file Error.cpp #include "Error.h"

Error::Error(int e) : _e(e) {}

Error::~Error() {}




This workaround has some implications, though. Firstly, the exported class will become a virtual class, and there is always a vtable constructed and defined along with the RTTI symbols which might be undesired.


Well, I hope that this workaround might be at least helpful and solves some issues. I would appreciate it, if you could report your own experience with this workaround, thanks.



Andreas







Andreas

Yep, that's the one...

If there is a flaw in dyld on 10.3.x, this would also mean, that dymically loaded DSOs (aka plugins) may not work correctly, even when they use dlopen() (with any flags specified) or other interfaces (NSBundle) since these are clients of dyld.


The only reasonable solution seems to be that Apple provides fixed system libraries, which are available as a regular update, or may be installed manually.

So, are there any official statements from Apple?

Andreas


Cheers,

Steve.

Steve Baxter
Software Development Manager
Improvision
+44-2476-692229


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Xcode-users mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Exceptions thrown from framework not caught in application (From: Walter <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Marshall Clow <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Steve Baxter <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Andreas Grosam <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Steve Baxter <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Andreas Grosam <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Steve Baxter <email@hidden>)
 >Re: Exceptions thrown from framework not caught in application (From: Andreas Grosam <email@hidden>)

  • Prev by Date: Re: Exceptions thrown from framework not caught in application
  • Next by Date: Re: Build errors
  • Previous by thread: Re: Exceptions thrown from framework not caught in application
  • Next by thread: undefined symbols
  • Index(es):
    • Date
    • Thread