Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

macOS: v10.13+ doesn't unload .dylibs with TLS #3002

Open
kinke opened this issue Feb 17, 2019 · 5 comments
Open

macOS: v10.13+ doesn't unload .dylibs with TLS #3002

kinke opened this issue Feb 17, 2019 · 5 comments

Comments

@kinke
Copy link
Member

kinke commented Feb 17, 2019

See #2839.

I firstly thought it was Xcode-specific, but tests with Azure have shown that it's got to be macOS 10.13 (as 10.13 + Xcode 9.2 fails too) - TLS changes?

Possibly related: #2820 and https://forum.dlang.org/thread/q0l0t6$2mnn$1@digitalmars.com.
@rainers
Copy link
Contributor

rainers commented Feb 17, 2019

Not sure if it's related, but at work we struggled with shared libraries not being unloaded with 10.13 (or even 10.12.6 IIRC). It turned out that Apple chose to disable unloading if the shared library uses implicit TLS.

kinke added a commit to kinke/ldc that referenced this issue Oct 25, 2019
@kinke
CircleCI: Bump the macOS image as well as host LDC & LLVM versions
5cf7600 
As our previous macOS image has been phased out, and we'd have to
downgrade to the xcode-9.0.1 image if we wanted to stick with macOS
10.12. xcode-11.1.0 is the newest image and comes with macOS 10.14,
so we'll probably hit issue ldc-developers#3002.

https://circleci.com/docs/2.0/testing-ios/#supported-xcode-versions
@kinke kinke mentioned this issue Oct 25, 2019
Merged
@kinke
Copy link
Member Author

kinke commented Oct 25, 2019

It turned out that Apple chose to disable unloading if the shared library uses implicit TLS.

Thanks, this seems to confirm this: rust-lang/rust#28794 (comment)
I assume DMD's CI machines feature some ancient macOS version and thus aren't hit by the same failure?

kinke added a commit to kinke/ldc that referenced this issue Oct 25, 2019
@kinke
druntime: Adapt test shared/finalize to recent macOS not unloading .d…
3ffc1e1 
…ylibs with TLS

Working around ldc-developers#3002.
@kinke
Copy link
Member Author

kinke commented Oct 25, 2019 •
edited
Loading

Well, all non-betterC .dylibs produced by LDC feature at least one TLS symbol, a TLS anchor used for registering with potentially shared druntime, so that's another LDC specificum (and why DMD might pass the test on newer macOS).

Edit: Nope, DMD should fail too, as the tested dylib contains explicit TLS symbols (here).

kinke added a commit to kinke/ldc that referenced this issue Oct 25, 2019
@kinke
druntime: Adapt test shared/finalize to recent macOS not unloading .d…
e7f5b14 
…ylibs with TLS

Working around ldc-developers#3002.
kinke added a commit to kinke/ldc that referenced this issue Oct 25, 2019
@kinke
druntime: Adapt test shared/finalize to recent macOS not unloading .d…
2f39bf3 
…ylibs with TLS

Working around ldc-developers#3002.
@kinke
Copy link
Member Author

kinke commented Oct 26, 2019

Btw, dlclose() returns non-zero in this case, so Runtime.unloadLibrary() returns false, and the user will be aware of the failed unloading.

@kinke kinke changed the title macOS: v10.13 breaks druntime test (shared/finalize) macOS: v10.13+ doesn't unload .dylibs with TLS Oct 26, 2019
@kinke
Copy link
Member Author

kinke commented Feb 4, 2020

Apparently, musl doesn't unload and run destructors either: dlang/druntime#2918

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rainers @kinke