Open MilesCranmer opened 5 months ago
My temporary workaround is to put this code:
if "juliacall" in sys.modules:
warnings.warn(
"juliacall module already imported. Make sure that you have set `PYTHON_JULIACALL_HANDLE_SIGNALS=yes` to avoid segfaults."
)
before the import statement.
Well firstly, packages shouldn't generally be setting global config such as that env var, though I understand why you're doing it.
Over in #219 I suggested adding a warning to set PYTHON_JULIACALL_HANDLE_SIGNALS=yes
if Julia is started with multiple threads. Do you think this would be a sufficient warning?
Also, given Julia starts with 1 thread by default, presumably you're already telling your users to set PYTHON_JULIACALL_NUM_THREADS
? In which case you can also tell them to set PYHON_JULIACALL_HANDLE_SIGNALS
?
If it helps, I was able to get a stacktrace for this:
This can also be avoided by setting the environment variable PYTHONFAULTHANDLER
to some writable file. Credit to @willow-ahrens for some of the heavy lifting on this, cc @mtsokol.
Affects: JuliaCall
Describe the bug
Related to https://github.com/JuliaPy/PythonCall.jl/issues/219. There's currently a scenario with no possible workaround other than forcing a downstream user to set up environment variables to avoid a segfault.
Say that I import a package which uses serial Julia code. That package runs
to start Julia.
Then, I import a different package. That package calls multithreaded Julia code, and thus to avoid a segfault (https://juliapy.github.io/PythonCall.jl/stable/faq/#Is-PythonCall/JuliaCall-thread-safe?) instead performs the import instead as:
However, at this point, the Julia runtime has already started. So now when I run a multithreaded portion of code, I will get a segfault, even though I implemented special workarounds in the multithreaded package.
How could I avoid this scenario? Indeed the user could always set up the environment variables themselves. But managing to figure this out from a random
bus error
will only be ~5% of users.