Skip to content

Segmentation fault when calling basic python functions #617

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.

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

Open
johannes-fischer opened this issue May 27, 2025 · 0 comments
Open

Segmentation fault when calling basic python functions #617

johannes-fischer opened this issue May 27, 2025 · 0 comments
Labels
bug Something isn't working

Comments

@johannes-fischer
Copy link

johannes-fischer commented May 27, 2025

Affects: PythonCall

Describe the bug
I get segmentation faults when using PythonCall to call python functions that create python objects many times. It does not happen deterministically, but happens (on a couple of systems I have tested it on) reliably for the MWE below:

using PythonCall
N = 100_000_000
for i in 1:N
    args = pytuple((2.0, 1.0, 0.0))
    @assert !pyeq(Bool, args[0], args[2]) # SEGFAULT
    if i % 100_000 == 0
        println("step $i ($(i/N*100) %)")
    end
end

Sometimes I get the segmentation fault immediately, before the first print statement, sometimes 30% of the loop succedes before the segfault.

If I wrap the doubles in Py objects explicitly before, I do not get segmentation faults:

using PythonCall
N = 100_000_000
for i in 1:N
    args = pytuple((Py(2.0), Py(1.0), Py(0.0)))
    @assert !pyeq(Bool, args[0], args[2]) # NO SEGFAULT
    if i % 100_000 == 0
        println("step $i ($(i/N*100) %)")
    end
end

My understanding is that this shouldn't be necessary to deal with explicitly, but somehow it is in this example. And since this is only a MWE it is not a solution to my actual problem, since I do not know which calls / arguments need this explicit handling and which do not.

Here is the segfault output (from the first code snippet):

[872756] signal 11 (1): Segmentation fault
in expression starting at /home/fischer/dev/jl/PythonCallSegFault/pythoncall_segfault_mwe.jl:5
do_richcompare at /usr/local/src/conda/python-3.12.10/Objects/object.c:815 [inlined]
PyObject_RichCompare at /usr/local/src/conda/python-3.12.10/Objects/object.c:865 [inlined]
PyObject_RichCompareBool at /usr/local/src/conda/python-3.12.10/Objects/object.c:887
PyObject_RichCompareBool at /home/fischer/.julia/packages/PythonCall/L4cjh/src/C/pointers.jl:303
unknown function (ip: 0x7efe9e9fca05)
unknown function (ip: 0x7efe9e9fc699)
unknown function (ip: 0x7efe9e9fc623)
macro expansion at /home/fischer/.julia/packages/PythonCall/L4cjh/src/Core/Py.jl:132 [inlined]
pyeq at /home/fischer/.julia/packages/PythonCall/L4cjh/src/Core/builtins.jl:304 [inlined]
top-level scope at /home/fischer/dev/jl/PythonCallSegFault/pythoncall_segfault_mwe.jl:12
jl_toplevel_eval_flex at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/toplevel.c:934
jl_toplevel_eval_flex at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/toplevel.c:886
ijl_toplevel_eval_in at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/toplevel.c:994
eval at ./boot.jl:430 [inlined]
include_string at ./loading.jl:2734
_include at ./loading.jl:2794
include at ./Base.jl:557
jfptr_include_46879.1 at /home/fischer/.julia/juliaup/julia-1.11.5+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
exec_options at ./client.jl:323
_start at ./client.jl:531
jfptr__start_73430.1 at /home/fischer/.julia/juliaup/julia-1.11.5+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
jl_apply at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/julia.h:2157 [inlined]
true_main at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/jlapi.c:900
jl_repl_entrypoint at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/src/jlapi.c:1059
main at /cache/build/tester-amdci5-12/julialang/julia-release-1-dot-11/cli/loader_exe.c:58
__libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x4010b8)
Allocations: 312994585 (Pool: 312994469; Big: 116); GC: 13
[1]    872756 segmentation fault  julia pythoncall_segfault_mwe.jl

Your system
Please provide detailed information about your system:

  • OS: Ubuntu 20.04
julia> versioninfo()
Julia Version 1.11.5
Commit 760b2e5b739 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 16 × 12th Gen Intel(R) Core(TM) i7-1260P
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 16 virtual cores)

julia> Pkg.status()
Status `~/dev/jl/PythonCallSegFault/Project.toml`
  [992eb4ea] CondaPkg v0.2.29
  [6099a3de] PythonCall v0.9.25

julia> CondaPkg.status()
CondaPkg Status /home/fischer/dev/jl/PythonCallSegFault/CondaPkg.toml (empty)
Environment
  /home/fischer/dev/jl/PythonCallSegFault/.CondaPkg/.pixi/envs/default

julia> pyimport("sys").version
Python: '3.12.10 | packaged by conda-forge | (main, Apr 10 2025, 22:41:16) [GCC 13.3.0]'

Additional context
The actual context where this happened to me is that I am using PythonCall.jl to use the python interface of the lanelet2 library, which in turn is a boost python interface to C++ code. I am getting segmentation faults from a couple of calls to this library.

@johannes-fischer johannes-fischer added the bug Something isn't working label May 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant