Certain import order triggers segmentation fault
Labels: module: crash, triaged, has workaround

### 🐛 Describe the bug

This bug is holding up the latest updates for the library pysr: https://github.com/MilesCranmer/PySR/ which depends on pytorch. cc @tttc3.

Basically: I see segmentation fault in PyTorch when importing another library which has a system interface. However, this depends on the import order:

- import torch, then the other library, I see a bug.
- import the other library, then torch, then I don't see a bug.

Here is a MWE (the other library is pyjulia - install with `pip install julia`):
```python
def do_something_torch():
    import torch

def do_something_julia():
    from julia import Pkg
    Pkg.activate("test", shared=True)
    Pkg.update()
```
on my macOS machine, running `do_something_torch()` and then `do_something_julia()` will trigger the following bug, which looks to come from `libtorch_cpu.dylib`. It seems like there is some interaction between the system calls of each library:
```
signal (11): Segmentation fault: 11
in expression starting at none:0
uv__io_start at /Users/mcranmer/venvs/main/lib/python3.8/site-packages/torch/lib/libtorch_cpu.dylib (unknown line)
uv__read_start at /Users/mcranmer/venvs/main/lib/python3.8/site-packages/torch/lib/libtorch_cpu.dylib (unknown line)
start_reading at ./stream.jl:793
wait_readnb at ./stream.jl:411
eof at ./stream.jl:106
jfptr_eof_42389 at /Applications/Julia-1.7.app/Contents/Resources/julia/lib/julia/sys.dylib (unknown line)
jl_apply_generic at /Applications/Julia-1.7.app/Contents/Resources/julia/lib/julia/libjulia-internal.1.7.dylib (unknown line)
eof at ./io.jl:416
#read_tarball#47 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Tar/src/extract.jl:344
read_tarball##kw at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Tar/src/extract.jl:340 [inlined]
#11 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:199 [inlined]
#open#700 at ./process.jl:395
open at ./process.jl:393 [inlined]
uncompress_registry at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:198
RegistryInstance at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:266
#reachable_registries#17 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:373
reachable_registries at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/registry_instance.jl:345 [inlined]
#download_default_registries#28 at /Users/sabae/src/julia/usr/share/julia/stdlib/v1.7/Pkg/src/Registry/Registry.jl:101

signal (11): Segmentation fault: 11
in expression starting at none:0
```
I see a similar issue on my CI's test suite which runs on linux with a different environment: https://github.com/MilesCranmer/PySR/runs/6715107004?check_suite_focus=true#step:12:31.

### Versions

(Note that I also see the bug in GitHub actions with different versions)

PyTorch version: 1.13.0.dev20220528
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.3.1 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (https://github.com/llvm/llvm-project.git ab3b89855c5318f0009e1f016ffe5b1483507fd0)
CMake version: version 3.22.3
Libc version: N/A

Python version: 3.8.9 (default, Apr 13 2022, 08:48:06)  [Clang 13.1.6 (clang-1316.0.21.2.5)] (64-bit runtime)
Python platform: macOS-12.3.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.2
[pip3] pytorch-lightning==1.5.10
[pip3] torch==1.13.0.dev20220528
[pip3] torchaudio==0.11.0
[pip3] torchmetrics==0.7.2
[pip3] torchvision==0.14.0a0+f0f8a3c
[conda] Could not collect