[BUG] Out-of-bounds read when solving a DataModel with lower/upper constraint bounds

Đang mở
  • Có gì không ổn?
#2,249 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ramakrishnap-nv đang làm issue này rồi.

Từ ngày 2/11/2026.

  • #2253 của @ramakrishnap-nv — đang mở
  • #2262 của @ramakrishnap-nv — đang mở
  • #2279 của @ramakrishnap-nv — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
Nửa ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
backend

Hướng nghiên cứu

Start with _compute_slack_csr, the function the report names as reading the rhs and sense arrays, and compare it with how a DataModel built through set_constraint_lower_bounds() and set_constraint_upper_bounds() fills those arrays. Run the reproducer in the issue, which should print slack near zero for x >= 1. Done means the slack is computed from the constraint bounds without reading the empty arrays, and the Cython bounds-checked run no longer reports an out-of-bounds access.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

(AI-assisted bug report)

cuopt.linear_programming.Solve accepts a DataModel whose constraints are supplied through set_constraint_lower_bounds() and set_constraint_upper_bounds(). When it constructs a Solution with a primal vector, its Python/Cython slack calculation instead reads the alternative RHS and row-sense arrays. Those arrays are empty for this valid DataModel representation. Because Cython bounds checking is disabled, the code reads outside both arrays. The read can produce an incorrect slack or terminate the process with SIGSEGV.

Reproducer:

import numpy as np
from cuopt.linear_programming.data_model import DataModel
from cuopt.linear_programming.solver import Solve
from cuopt.linear_programming.solver_settings import SolverMethod, SolverSettings

# Minimize x subject to x >= 1.
dm = DataModel()
dm.set_csr_constraint_matrix(
    np.array([1.0]),
    np.array([0], dtype=np.int32),
    np.array([0, 1], dtype=np.int32),
)
dm.set_objective_coefficients(np.array([1.0]))
dm.set_variable_lower_bounds(np.array([0.0]))
dm.set_variable_upper_bounds(np.array([np.inf]))
dm.set_variable_types(np.array(["C"], dtype="S1"))
dm.set_constraint_lower_bounds(np.array([1.0]))
dm.set_constraint_upper_bounds(np.array([np.inf]))

print(
    "rows=1",
    "rhs=", len(dm.get_constraint_bounds()),
    "sense=", len(dm.get_row_types()),
    "lower=", len(dm.get_constraint_lower_bounds()),
    "upper=", len(dm.get_constraint_upper_bounds()),
    flush=True,
)
settings = SolverSettings()
settings.set_parameter("method", SolverMethod.PDLP)
settings.set_parameter("log_to_console", False)
solution = Solve(dm, settings)
print(solution.get_termination_reason())
print("x=", solution.get_primal_solution())
print("slack=", solution.get_slack())

Observed locally:

rows=1 rhs= 0 sense= 0 lower= 1 upper= 1
Optimal
x= [1.]
slack= [-1.]

The constraint is x >= 1 so we'd expect the slack to be zero. I observed segfaults on other instances.

The source of the issue is _compute_slack_csr which reads from the rhs and sense vectors which aren't initialized in this DataModel code path. Running with bounds checking enabled in Cython confirms the out of bounds access.

Ngôn ngữ chính
Cuda
Star
1.1k
Fork
255
Merge trung bình
1 ngày 11 giờ
Pull request đã merge (30 ngày)
123

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của NVIDIA/cuopt

Tất cả issue của NVIDIA/cuopt

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.