[D-runtime] Runtime issue on Mac OS X

[Jacob Carlborg]

When I was trying to fix issue 7995 I created the pull request:

https://github.com/D-Programming-Language/druntime/pull/228

In that pull request it has come to my attention that following system functions doesn't play nice with dynamic libraries:

_dyld_register_func_for_add_image
_dyld_register_func_for_remove_image

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html

This two functions are used in memory_osx.d to install callbacks for getting various data out of the loaded images, like TLS data, module infos, exception handling tables and so on. These callbacks are called, among other cases, when dlopen/dlclose is called.

In the discussion in the pull request dawgfoto (Martin Nowak) pointed out that it's not very good to use any of the above two functions in a dynamic library loaded via "dlopen".

The problem is that the callbacks are never removed from the internal list of callbacks. So if a dynamic library uses these functions and then gets unloaded. Next time dlopen/dlclose is called the application will crash because it tries to call the callback from the now unloaded library.

There doesn't seem to be a way to unregister these callbacks.

This example shows the problem

http://pastebin.com/yUKBgu8Y

When running "main" from the above a Bus error will occur.

I did some digging and found a solutions that seems to work:

http://pastebin.com/qZfiWRbN

The only difference compared to the implementation we have now is that the callback called when unloading a dylib is not called for the dylib that installed it. In the example above that would mean that "onUnload" is not called when foo.dylibis unloaded. Note that the callback is still called when bar.dylibis unloaded.

The problem with the implementation above is that "dyld_register_image_state_change_handler" is a private undocumented function in libdyld.dylib. This function has been available since Mac OS X 10.5 and is used by the Objective-C runtime.

All of this is only an issue if the D runtime is dynamically loaded, which isn't supported yet.

-- 
/Jacob Carlborg