perform runtime and module initialization when loading DSOs #590
Conversation
- When calling rt_init/rt_term from ELF's .ctors/.dtors section atexit runs before rt_term, which causes a crash because the thread locks are already destroyed.
- runModuleUnitTests is no longer called from rt_init but needs to be called separatly
reuse rt_init/rt_term in main
add explicit thread_term call to replace atexit
|
You should say that this supercedes #583 But there is a synchronization problem with it. When an exception is thrown, DSO.opAppy() gets called, and _static_dso[] is walked. But if, during this walk, another thread loads/unloads a library, then the former version of _static_dso[] points to garbage, and it crashes. This is also why the 'nothrow' was added to deh_win64_posix.d. |
| unregisterGCRanges(pdso); | ||
| assert(pdso._tlsSize == _tlsRanges.back.length); | ||
| _tlsRanges.popBack(); | ||
| assert(pdso == _static_dsos.back); // static DSOs are unloaded in reverse order | ||
| _static_dsos.popBack(); |
There was a problem hiding this comment.
What happens if dll A is dynamically loaded, then dll B is dynamically loaded, then dll A is unloaded? The assert in line 194 will fail. The code in #583 deals with that case.
There was a problem hiding this comment.
I'm about to prepare another pull for dynamic loading so the issue doesn't apply here.
Interesting problem, didn't knew about this. But again it will only apply to dynamic loading which isn't part of this pull request. |
|
As far as I can see, #583 has a serious issue w.r.t. only picking up symbols from the libphobos so (see Martin's comment), doesn't it? |
perform runtime and module initialization when loading DSOs
|
This caused a regression Issue 10976 and here is the fix #600. |
depends on #587 and #589