Memory allocated when creating Python objects is never automatically freed
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- performance
Hướng nghiên cứu
Bắt đầu bằng cách chạy createmodel() CP-SAT MWE được cung cấp với PythonCall và CondaPkg, sau đó so sánh tác động của PythonCall.pydel!(...) và GC.gc(). Truy vết các điểm vào liên quan đến vòng đời đối tượng và garbage collection của PythonCall; hoàn thành khi các lần gọi lặp lại giải phóng các allocation nằm ngoài phạm vi mà không yêu cầu GC thủ công.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Affects: PythonCall
Describe the bug
I am trying to use PythonCall.jl to call the Python interface to CP-SAT, which is a popular constraint programming library from Google's OR-Tools toolkit. The problem is that the memory that gets allocated when creating a Python object from that interface is never automatically freed.
A function createmodel() is used to create a CpModel object`, which goes out of scope after the function terminates. Each time the function is executed, the memory gets fuller, until eventually the Julia process gets killed. The expected behavior is that at some point before Julia gets killed, the memory that was allocated for objects that are out of scope should get released.
Here are the steps to reproduce a MWE, assuming the environment already has PythonCall.jl and CondaPkg.jl:
Add OR-Tools to the environment and import it:
using PythonCall, CondaPkg
] conda pip_add ortools
cp_model = pyimport("ortools.sat.python.cp_model")
Define the function that will create and initialize a CpModel object:
createmodel() = let
model = cp_model.CpModel() # create model
variables = [model.new_int_var(0,1, "x_" * string(i)) for i in 1:100] # add variables to the model
model.add_allowed_assignments(variables, [rand(0:1, 100) for _ in 1:200000]) # add constraints over those variables
return nothing
end
Repeatedly call createmodel() and observe that the memory usage keeps going up until the Julia process gets killed.
createmodel()
createmodel()
createmodel()
# ... if you keep calling createmodel(), eventually the memory gets full
Your system
Please provide detailed information about your system:
-
Operating System: Fedora Linux 43
-
Python version: 3.14.3
-
versioninfo()Julia Version 1.12.3 Commit 966d0af0fdf (2025-12-15 11:20 UTC) Build Info: Official https://julialang.org release Platform Info: OS: Linux (x86_64-linux-gnu) CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz WORD_SIZE: 64 LLVM: libLLVM-18.1.7 (ORCJIT, tigerlake) GC: Built with stock GC Threads: 1 default, 1 interactive, 1 GC (on 8 virtual cores) -
import Pkg; Pkg.status()Status `~/MWECPSAT/Project.toml` [992eb4ea] CondaPkg v0.2.34 [6099a3de] PythonCall v0.9.31 -
import CondaPkg; CondaPkg.status()Environment /home/dmaioli/MWECPSAT/.CondaPkg/.pixi/envs/default Pip Packages ortools v9.15.6755
Additional context
- Calling
PythonCall.pydel!(model)and/orfor v in variables PythonCall.pydel!(v) endinside the body of the function does not have any visible effect - Executing
GC.gc()after the function calls has the effect that at least part of the allocated memory gets freed, but sometimes this does not happen if it is executed only once. - Calling the equivalent code directly from Python works as expected, i.e. the memory gets freed after the function terminates. Here is the Python version:
from ortools.sat.python import cp_model import randomdef createmodel(): model = cp_model.CpModel() variables = [model.new_int_var(0,1, f"x_{i}") for i in range(100)] model.add_allowed_assignments(variables, [[random.randint(0,1) for _ in range(100)] for _ in range(200000)]) return Nonecreatemodel() createmodel() createmodel() # ... if you keep calling createmodel(), the memory never gets full
- Ngôn ngữ chính
- Julia
- Star
- 1.1k
- Fork
- 89
- Merge trung bình
- 2 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 7
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của JuliaPy/PythonCall.jl
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
JuliaPy/PythonCall.jl#828 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
JuliaPy/PythonCall.jl#809 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Locking julia dependenciesĐang mởenhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
JuliaPy/PythonCall.jl#805 · 4 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 68/100
JuliaPy/PythonCall.jl#796 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
enhancement
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
JuliaPy/PythonCall.jl#790 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của JuliaPy/PythonCall.jl
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
oxfordcontrol/COSMO.jl#211 ·
-
documentation
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 6 ngày
-
Out-of-place JLArray/GPU problem with VectorContinuousCallback scalar-indexes (callback cache built with CPU zeros)Có thể đã có người làm @ChrisRackauckas-Claude đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
SciML/OrdinaryDiffEq.jl#4813 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
ARKODE: callbacks that modify `u` throw MethodError on reinitCó thể đã có người làm @devmotion đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 79/100
SciML/Sundials.jl#575 ·
-
broken links in docsĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày