Segfault on propertynames

Affects: PythonCall / JuliaCall / Both [delete as appropriate]

Describe the bug

Using Python 3.12.8 and Julia 1.11, when I type <pyobject>. into the REPL, I see a segfault.

Your system

julia> versioninfo()
Julia Version 1.11.2
Commit 5e9a32e7af2 (2024-12-01 20:02 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 64 × AMD Ryzen Threadripper 3970X 32-Core Processor
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver2)
Threads: 60 default, 0 interactive, 30 GC (on 64 virtual cores)
Environment:
  JULIA_NUM_THREADS = 60
  JULIA_PROJECT = @.
  JULIA_EDITOR = emacs -nw

(...) pkg> st
Project HunFlair2 v0.1.0
Status `~/.../Project.toml`
  [992eb4ea] CondaPkg v0.2.24
  [6099a3de] PythonCall v0.9.23

(...) pkg> conda st
CondaPkg Status /.../CondaPkg.toml
Environment
  /.../.CondaPkg/env
Pip packages
  flair v0.14.0

Additional context

julia> s.
[57673] signal 11 (1): Segmentation fault
in expression starting at none:0
_PyInterpreterState_GET at /usr/local/src/conda/python-3.12.8/Include/internal/pycore_pystate.h:133 [inlined]
_PyType_Lookup at /usr/local/src/conda/python-3.12.8/Objects/typeobject.c:4729 [inlined]
_PyObject_LookupSpecial at /usr/local/src/conda/python-3.12.8/Objects/typeobject.c:2167
_dir_object at /usr/local/src/conda/python-3.12.8/Objects/object.c:1758 [inlined]
PyObject_Dir at /usr/local/src/conda/python-3.12.8/Objects/object.c:1790
PyObject_Dir at /home/tec/.julia/packages/PythonCall/Nr75f/src/C/pointers.jl:303 [inlined]
macro expansion at /home/tec/.julia/packages/PythonCall/Nr75f/src/Core/Py.jl:132 [inlined]
pydir at /home/tec/.julia/packages/PythonCall/Nr75f/src/Core/builtins.jl:216
propertynames at /home/tec/.julia/packages/PythonCall/Nr75f/src/Core/Py.jl:293
unknown function (ip: 0x7fab413505eb)
complete_symbol at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/usr/share/julia/stdlib/v1.11/REPL/src/REPLCompletions.jl:208
[...]

I see that crash trying to use the Matlab PythonAPI installed in a conda venv:

               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.3 (2025-01-21)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

julia> using PythonCall

julia> me = pyimport("matlab.engine")
[long delay]
Python: <module 'matlab.engine' from '/home/sjbespa/.conda/envs/v3.12/lib/python3.12/site-packages/matlab/engine/__init__.py'>

julia> me.
[3507720] signal 11 (1): Segmentation fault
in expression starting at none:0
_PyInterpreterState_GET at /usr/local/src/conda/python-3.12.8/Include/internal/pycore_pystate.h:133 [inlined]
_PyType_Lookup at /usr/local/src/conda/python-3.12.8/Objects/typeobject.c:4729 [inlined]
_PyObject_LookupSpecial at /usr/local/src/conda/python-3.12.8/Objects/typeobject.c:2167
_dir_object at /usr/local/src/conda/python-3.12.8/Objects/object.c:1758 [inlined]
PyObject_Dir at /usr/local/src/conda/python-3.12.8/Objects/object.c:1790```

(@v1.11) pkg> status
Status ~/.julia/environments/v1.11/Project.toml
[8f4d0f93] Conda v1.10.2
[992eb4ea] CondaPkg v0.2.24
[497a8b3b] DoubleFloats v1.4.2
[6099a3de] PythonCall v0.9.24

@tecosaur

Thanks both for reporting this. However I cannot reproduce this locally, e.g. I can do:

julia> using PythonCall

julia> x = pyint(3)
Python: 3

julia> x.
__abs__            __add__            __and__            __bool__           [etc.....]

@tecosaur You didn't specify what s is in your example. Does the error occur with any Python object, or just certain ones? I notice you started Julia with multithreading, do you still get the error with one thread?

@protogeezer I can't install matlabengine because I don't have matlab. Have you seen the problem elsewhere?

Edit: I tried reproducing on Windows and on Linux, with 1 thread and with many.

Fair enough. I submitted #591 (mentioned above) with more details. I tried the simple test you described - it didn't work here - it hung. However the regular expression example from the documentation still crashes as soon as I try to reference the imported regular expression module.

One additional detail is that I use python from Miniforge3. I do not use the base environment.

If you need further experiments, please let me know. Try more versions of Python? Do we need to use the "built in" version of python"?

I have contemplated getting more involved with this package because I depend on it so much. I would need some coaching to get off the ground. Actually even how to get on the runway... I did get to the point where I was fixing crashes in PyCall before PythonCall came along...

Stephen

(base) sjbespa@mbp-et ~ % julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.3 (2025-01-21)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |

(@v1.11) pkg> build PythonCall

(@v1.11) pkg> build PythonPlot

julia> using PythonCall

julia> x = pyint(3)
Python: 3

julia> x.
       ^C

julia> re = pyimport("re")
Python: <module 're' from '/opt/Miniforge3/lib/python3.12/re/__init__.py'>

julia> re.
[6482] signal 11 (2): Segmentation fault: 11
in expression starting at none:0
_PyType_Lookup at /opt/Miniforge3/lib/libpython3.12.dylib (unknown line)
PyObject_Dir at /opt/Miniforge3/lib/libpython3.12.dylib (unknown line)
...

One additional detail is that I use python from Miniforge3.

Can you give the steps to reproduce your environment please? Including versions of downloaded software and any settings you set.

@tecosaur

@tecosaur You didn't specify what s is in your example. Does the error occur with any Python object, or just certain ones? I notice you started Julia with multithreading, do you still get the error with one thread?

I had the impression it may be with any object, but it was originally with a module and I've just run into it again so I can give a more detailed reproducer:

~$ mkdir /tmp/pytest; cd /tmp/pytest

~$ julia +1.12 --startup-file=no --project=. -q

pkg> add PythonCall

julia> using PythonCall

pkg> conda pip_add DSPy

julia> const dspy = pyimport("dspy")

julia> dspy.<tab>
ERROR: Python: ImportError: C extension: pickle not built. If you want to import pandas from the source directory, you may need to run 'python setup.py build_ext' to build the C extensions first.
Python stacktrace: [...]

julia> exit()
[544212] signal 7 (128): Bus error
in expression starting at none:0
_PyErr_Occurred at /usr/local/src/conda/python-3.12.9/Include/internal/pycore_pyerrors.h:23 [inlined]
...

~$ julia +1.12 --startup-file=no --project=. -q

julia> using PythonCall

julia> const dspy = pyimport("dspy")
Python: <module 'dspy' ...>

julia> dspy.<tab>
[545473] signal 11 (1): Segmentation fault
in expression starting at none:0
_PyInterpreterState_GET at /usr/local/src/conda/python-3.12.9/Include/internal/pycore_pystate.h:133 [inlined]
_PyType_Lookup at /usr/local/src/conda/python-3.12.9/Objects/typeobject.c:4729 [inlined]
_PyObject_LookupSpecial at /usr/local/src/conda/python-3.12.9/Objects/typeobject.c:2167
_dir_object at /usr/local/src/conda/python-3.12.9/Objects/object.c:1758 [inlined]
PyObject_Dir at /usr/local/src/conda/python-3.12.9/Objects/object.c:1790
PyObject_Dir at /home/tec/.julia/packages/PythonCall/WMWY0/src/C/pointers.jl:303 [inlined]
macro expansion at /home/tec/.julia/packages/PythonCall/WMWY0/src/Core/Py.jl:132 [inlined]
pydir at /home/tec/.julia/packages/PythonCall/WMWY0/src/Core/builtins.jl:216
propertynames at /home/tec/.julia/packages/PythonCall/WMWY0/src/Core/Py.jl:293

Seems like this actually gives you two different errors for the price of one, fun! 😛

Since this was starting from an empty project using Julia 1.11.3 and the same system as the original issue, I think this should be all the relevant information?

I notice you started Julia with multithreading, do you still get the error with one thread?

Huh, it seems alright if only one thread is used.

Those examples are with Julia 1.12 which doesn't exist yet (??) do you get the same on 1.11?

Ah oops, I meant to use 1.11 but mis-typed. Yep, it's the same experience.

I have some news to report. Pursuant to Chris's request, a couple days ago, for the steps to reproduce my environment, what I was doing to create the recipe seems to have made things somewhat better.

Here is the example from the beginning of the PythonCall guide that didn't work (see the crash in a previous comment).

julia> using PythonCall

julia> re = pyimport("re")
Python: <module 're' from '/opt/Miniforge3/lib/python3.12/re/__init__.py'>

julia> words = re.findall("[a-zA-Z]+", "PythonCall.jl is very useful!")
Python: ['PythonCall', 'jl', 'is', 'very', 'useful']

julia> sentence = Py(" ").join(words)
Python: 'PythonCall jl is very useful'

julia> "PythonCall jl is very useful"
"PythonCall jl is very useful"

However, Chris's previous example still crashes:

julia> x = pyint(3)
Python: 3

julia> x.
[1338] signal 11 (2): Segmentation fault: 11
in expression starting at none:0
_PyType_Lookup at /opt/Miniforge3/lib/libpython3.12.dylib (unknown line)
PyObject_Dir at /opt/Miniforge3/lib/libpython3.12.dylib (unknown line)
PyObject_Dir at /Users/sjbespa/.julia/packages/PythonCall/WMWY0/src/C/pointers.jl:303 [inlined]

At this point I've tried deleting the "official" macOS julia app (which stopped working for some reason - the error message had something to do with not being able to launch an app(?) in a terminal window); several old versions of julia that I built for analysis (which has now been obviated by juliaup); and finally I deleted and rebuilt the 1.11 env and reinstalled PythonCall. I suppose I could try deleting .julia to see if the problem really is a software conflict rather than a bug.

I'll try to finish rooting out possible conflicts in the next few days.

Stephen

I have developed a simpler set of steps to cause the crash. This is what happens on the Dell XPS 17 3790 running Kubuntu 24.10:

(base) sjbespa@gauss:~$ rm -rf .julia
(base) sjbespa@gauss:~$ julia
Checking for new Julia versions
Installing Julia 1.11.3+0.x64.linux.gnu
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.11.3 (2025-01-21)
 _/ |\__'_|_|_|\__'_|  |  Official https://julialang.org/ release
|__/                   |
(@v1.11) pkg> add PythonCall
  Installing known registries into `~/.julia`
       Added `General` registry to ~/.julia/registries
    Updating registry at `~/.julia/registries/General.toml`
   Resolving package versions...
   ...
julia> using PythonCall
julia> x = pyint(3)
Python: 3

julia> x.
[42889] signal 11 (1): Segmentation fault
in expression starting at none:0
_PyInterpreterState_GET at /usr/local/src/conda/python-3.12.9/Include/internal/pycore_pystate.h:133 [inlined]
_PyType_Lookup at /usr/local/src/conda/python-3.12.9/Objects/typeobject.c:4729 [inlined]
...

The paths in the call stack appear to be gibberish - the majority certainly aren't paths that exist on the machine.

Here are the relevant settings in the .bashrc file:

export JULIA_NUM_THREADS=$(nproc);

export PYTHONDIR="/opt/Miniforge3"
export PYTHONPATH="/opt/Miniforge3/bin/python3"
export MATLAB_HOME="/usr/local/MATLAB/2024b/"

export CONDA_JL_CONDA_EXE="/opt/Miniforge3/bin/conda"
#export CONDA_JL_USE_MINIFORGE=1
export JULIA_CONDAPKG_EXE="/opt/Miniforge3/bin/conda"
export JULIA_CONDAPKG_BACKEND="System"
export JULIA_PYTHONCALL_EXE=$PYTHONPATH

export PATH="$PATH:$MATLAB_HOME/bin:"
export PATH="/opt/Miniforge3/bin:/opt/Miniforge3/sbin:$PATH"
export PATH="/opt/Miniforge3/lib:/opt/Miniforge3/libexec:$PATH"

These variable setting appear to work on macOS Sequoia (15.3) on a MBP with Apple Silicon. I'll continue to try to narrow down the example. Both Miniforge3 is writeable on both machines.

I hope this is useful.

Stephen

This somehow could prevent the Segmentation fault

struct Module
    name::Symbol
    py::Py
    attributes::Ref{Vector{Symbol}}
end

Module(name) = Module(name, pynew(), Ref{Vector{Symbol}}())

const numpy = Module(:numpy)

is_public_attribute(name) = !startswith(string(name), "__")

function __init__()
    PythonCall.pycopy!(numpy.py, pyimport("numpy"))
    numpy.attributes[] = filter(is_public_attribute, propertynames(numpy.py))
end

Base.propertynames(m::Module) = m.attributes[]

@Beforerr

@Beforerr: could you be a bit more specific about where your code should go?

With more testing I could soon conclude that the crash tecosaur and I reported depends only on the version of python that PythonCall is configured with. So far, I have been unable to reproduce the crash with python 3.11. Not so with Python 3.12. So far this pattern holds on a MacBook Pro M1 running sequoia, and a Dell with an i9 running Ubuntu 24.10.

Stephen

It is just a workaround (putting attributes into Julia so propertynames would not call py related function).

P.S:. It also happens in Mac Studio M2, M1 and Python 3.11

@Beforerr

@Beforerr: That's disappointing. If it's not the version of python, it could mean it's the values in the environment variables for Conda, CondaPkg and/or PythonCall? I'll experiment more with that in mind. Just now I was able to do the example of assigning a pyint to x, then hitting x., which resulted in a nice list of about 4 dozen methods. That never worked until I did many experiments with setting up the condo or python env. And varied the version of python.

If you add a comment with the steps to lead to the crashes that you are seeing, I'll try them too, and the workaround you proposed.

Stephen

Add logging of threadid

Yeah that seems to be spot on. Ran it with c934d80:

Works with 1 interactive thread when both run on the same inteactive thread:

julia> using PythonCall
┌ Info: init_context()
│   threadid() = 1
│   nthreads(:interactive) = 1
└   nthreads(:default) = 12

julia> x = pyint(3)
Python: 3

julia> x.┌ Info: propertynames(x::Py)
│   threadid() = 1
│   nthreads(:interactive) = 1
└   nthreads(:default) = 12

__abs__            __add__

Fails with 0 or more than 1 interactive threads when both run on different threads:

julia> using PythonCall
┌ Info: init_context()
│   threadid() = 1
│   nthreads(:interactive) = 2
└   nthreads(:default) = 12

julia> x=pyint(3)
Python: 3

julia> x.┌ Info: propertynames(x::Py)
│   threadid() = 2
│   nthreads(:interactive) = 2
└   nthreads(:default) = 12

Please submit a bug report with steps to reproduce this fault, and any error messages that follow (in their entirety). Thanks.
Exception: EXCEPTION_ACCESS_VIOLATION

Thanks, I can reproduce this on Linux now.

OK so we can conclude that if there are multiple interactive threads then tab-completion and package-importing can happen on different threads, which is bad. And if there are none, then presumably Julia puts interactive stuff on the default threads, so if there are multiple of those then same problem. So we require exactly one interactive thread, or exactly one thread.

I don't think there's anything that we can fix in PythonCall is there? I think all we can do is detect that this is occurring (by saving threadid() at init and checking if it's different in propertynames(::Py)) and print a warning with some advice. And put this info into the FAQ.

OK maybe there is something we can do for this specific issue - have a long-running task whose job is to compute propertynames(x) where x is read from a channel, writing the result to another channel. Then inside propertynames(::Py), check if we are on the "main" thread, if so continue as normal, but if not then fire a query off to this task.

Calling propertynames(x) doesn't segfault, but via REPLCompletions it does. See the full stacktrace for the REPLCompletions path: #586 (comment)

I don't know much about the REPL or how thread safety is supported in this package besides reading the multi-threading docs. But do I correctly understand that calling Python concurrently is only safe if the user locks the GIL? So if say the REPL does concurrent Python calls via e.g. propertynames, it cannot know about this and thus triggers the segfault?

I see #627 has some discussion on using Julia locks on the GIL, I supposed that may help here as well?

There is also JuliaLang/julia#50084 which suggests defaulting to 1 interactive thread. Won't help with 2+ interactive threads specified by the user, but I assume most run into this because they use JULIA_NUM_THREADS=x. Luckily from Julia 1.12 JULIA_NUM_THREADS=x will default to 1 interactive thread.

After reading #635 (comment) I looked a bit more into the GIL with these Python docs.

The tab completion works if I we can acquire the GIL in the non-main Julia thread that calls propertynames. We cannot acquire it since the main Julia thread locks it by default. But if I manually release it from the main thread, and wrap the body of propertynames in GIL.@lock it works.

using PythonCall
using PythonCall: GIL, C

x = pyint(3)

# unlock the GIL
state = C.PyEval_SaveThread()

x.<tab>  # works!

Of course I'd have to reacquire the GIL if you want to run any other Python code from Julia. But it makes me wonder if we should release the GIL by default, and lock if for any Python C API call we do.

Add FAQ on interactive threads

Add FAQ on interactive threads (#638)

There is also JuliaLang/julia#50084 which suggests defaulting to 1 interactive thread. Won't help with 2+ interactive threads specified by the user, but I assume most run into this because they use JULIA_NUM_THREADS=x. Luckily from Julia 1.12 JULIA_NUM_THREADS=x will default to 1 interactive thread.

I'm running Julia 1.12-rc3, and for me the default setting of 1 interactive thread doesn't work 🤔 Unless I start Julia with -t 1 it'll still segfault on tab-completion.

Same here on Macos, julia -tauto,1, verified that there's only one interactive thread, still segfaults when doing

using PythonCall
pd = pyimport("pandas")
pd.

results in

[84961] signal 11 (2): Segmentation fault: 11
in expression starting at REPL[7]:1
_PyType_LookupRef at /Users/<user>/.julia/dev/Dev/.CondaPkg/.pixi/envs/default/lib/libpython3.13.dylib (unknown line)
PyObject_Dir at /Users/<user>/.julia/dev/Dev/.CondaPkg/.pixi/envs/default/lib/libpython3.13.dylib (unknown line)
PyObject_Dir at /Users/<user>/.julia/packages/PythonCall/mkWc2/src/C/pointers.jl:300 [inlined]
macro expansion at /Users/<user>/.julia/packages/PythonCall/mkWc2/src/Core/Py.jl:118 [inlined]
pydir at /Users/<user>/.julia/packages/PythonCall/mkWc2/src/Core/builtins.jl:191
propertynames at /Users/<user>/.julia/packages/PythonCall/mkWc2/src/Core/Py.jl:270
unknown function (ip: 0x132da034f) at (unknown file)
#complete_symbol!#6 at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/REPLCompletions.jl:230
complete_symbol! at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/REPLCompletions.jl:184
unknown function (ip: 0x132d8807f) at (unknown file)
completions at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/REPLCompletions.jl:1150
#complete_line#66 at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/REPL.jl:809
complete_line at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/REPL.jl:807
unknown function (ip: 0x132b48533) at (unknown file)
#complete_line_named#17 at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/LineEdit.jl:401
complete_line_named at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/LineEdit.jl:400 [inlined]
macro expansion at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/LineEdit.jl:442 [inlined]
macro expansion at ./lock.jl:376 [inlined]
#check_show_hint##2 at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/usr/share/julia/stdlib/v1.12/REPL/src/LineEdit.jl:439
jfptr_YY.check_show_hintYY.YY.2_18133.1 at /Users/<user>/.julia/juliaup/julia-1.12.1+0.aarch64.apple.darwin14/share/julia/compiled/v1.12/REPL/u0gqU_vMi9E.dylib (unknown line)
jl_apply at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/src/./julia.h:2391 [inlined]
start_task at /Users/julia/.julia/scratchspaces/a66863c6-20e8-4ff4-8a62-49f30b1f605e/agent-cache/default-honeycrisp-XG3Q6T6R70.0/build/default-honeycrisp-XG3Q6T6R70-0/julialang/julia-release-1-dot-12/src/task.c:1249
Allocations: 17932670 (Pool: 17932429; Big: 241); GC: 40
zsh: segmentation fault  julia -tauto,1

BTW, same story with python 3.12

With julia 1.11.7 everything works fine with both python 3.12 and 3.13

This was fixed in #677 but not released yet. Please try the fix with pkg> add PythonCall#main.

True, thanks!

Navigation Menu

Repository navigation

Segfault on propertynames #586

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Segfault on propertynames #586

Description

Activity

protogeezer commented on Jan 23, 2025

cjdoris commented on Feb 22, 2025

protogeezer commented on Feb 22, 2025

cjdoris commented on Feb 23, 2025

tecosaur commented on Feb 24, 2025

tecosaur commented on Feb 24, 2025

cjdoris commented on Feb 24, 2025

tecosaur commented on Feb 25, 2025

protogeezer commented on Feb 25, 2025

protogeezer commented on Mar 2, 2025

Beforerr commented on Mar 5, 2025

protogeezer commented on Mar 5, 2025

Beforerr commented on Mar 6, 2025

protogeezer commented on Mar 6, 2025

9 remaining items

visr commented on Jul 2, 2025

cjdoris commented on Jul 2, 2025

cjdoris commented on Jul 2, 2025

visr commented on Jul 6, 2025

visr commented on Jul 6, 2025

JamesWrigley commented on Oct 5, 2025

hhaensel commented on Oct 22, 2025

hhaensel commented on Oct 22, 2025

hhaensel commented on Oct 22, 2025

cjdoris commented on Oct 22, 2025

hhaensel commented on Oct 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions