I have a few questions regarding ABI, ODR, and the Runtime Link-Loader.
Here's the scenario that Crypto++ was taking bug reports on when
maintainers decided to start packaging Crypto++ as a DSO.
==========
+----- Some Plugin/DSO 1 -----\
| \
apache -----+ +----- Crytpo++ DSO
| /
+----- Some Plugin/DSO 1 -----/
* (best viewed with fixed font)
==========
Crypto++ DSO declares a global C++ class which has a destructor. Call
it g_Global. g_Global is declared once in Crypto++, and storage is
allocated for it
Crypto++ DSO .
Apache, Some Plugin/DSO 1, and Some Plugin/DSO 2 do not
declare it and do not provide a storage allocation for it.
==========
Apache loads Some Plugin/DSO 1. The constructor for g_Global is executed.
Apache loads Some Plugin/DSO 2. The constructor for g_Global *IS NOT* executed.
==========
Apache unloads Some Plugin/DSO 1. The destructor for g_Global *IS* executed.
Apache unloads Some Plugin/DSO 2. The destructor for g_Global *IS*
executed. <== Crash*
* (Crash might occur while Some Plugin/DSO 2 runs since the object has
been yanked out from under it. But it will surely occur on destruction
due to a double free)
==========
A reasonable/sane choice was made for the constructor. If a
reasonable/sane choice was made for the destructor, Crypto++ and
countless others would not have a crash.
==========
Where did Crypto++ violate ODR? Crypto++ provided one declaration, and
one definition. Period.
Why are the constructors not being executed twice?
Why are the destructors not being executed once?
==========
Unacceptable (two bugs)
(1) Since behavior for construction and destruction differ, (I expect
one behavior or another), I claim there is a bug in the runtime
link-loader.
(2) The runtime link-loader's handling of two Intermediate DSOs
including a common DSO is faulty. Its readily apparent that the
runtime link-loader cannot handle a flat namespace - which it created
in the first damn place (perhaps due to the ABI). I claim this is a
bug also.
==========
Acceptable (with one bug)
(1) Apache, Some Plugin/DSO 1, Some Plugin/DSO 2, and Crypto++ *each*
declare and allocate storage for g_Global, and its [miraculously] of
the same type. The runtime link-loader folds the symbols according to ODR.
(2) One constructor for g_Global
(3) Four destructors run on g_Global
The crash due to (3) is not a bug since its documented (RTFM).
However, the behavior regarding (2) and (3) is clearly broken - I
expect one behavior or another; and not a split of the behavior.
Jeff
