IGC heap corruption compiling findmax's reduction kernel on Julia 1.12 with --check-bounds=yes
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
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- compilers
Hướng nghiên cứu
The crash is inside libigc.so, not in this repo, so start by reproducing it: compile the attached repro.spvasm with ocloc compile -spirv_input for tgllp, or run findmax(abs, x) on Julia 1.12 with --check-bounds=yes. The issue points to upstream commit 522dc7026a6d0b13da721d3364c053b4ee1673b7, which adds insertvalue handling for non-extract users of *.with.overflow intrinsics. Done means the PHI repro compiles and the GPUArrays indexing find test passes on 1.12.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
On Julia 1.12, the GPUArrays testsuite's gpuarrays/indexing find test kills its worker while compiling a kernel:
free(): invalid next size (fast)
[108861] signal 6 (-6): Aborted
__libc_free at /lib/x86_64-linux-gnu/libc.so.6
unknown function at .../libigc.so
...
IGC::IgcOclTranslationCtx<0ul>::Impl::Translate(...) at .../libigc.so
L0::ModuleTranslationUnit::compileGenBinary(...) at .../libze_intel_gpu.so.1
L0::zeModuleCreate(...)
link_kernel at src/compiler/compilation.jl:366
...
mapreduce_1d_gpu at AcceleratedKernels/src/reduce/mapreduce_1d_gpu.jl:109
...
findmax at GPUArrays/src/host/indexing.jl:309
GPUArrays/test/testsuite/indexing.jl:234
Sometimes it's a segfault in libigc.so instead of the abort; it's heap corruption. This has failed the Julia 1.12 job on main since #665 (GPUArrays 12, which routes findmax through AcceleratedKernels' _mapreduce_block!): 1785, 1799, 1800. The 1.10, 1.11, 1.13 and nightly jobs pass, and pull requests don't run 1.12, so it didn't show up before the merge. It also reproduces locally on main (fa0f23a2) on an Iris Xe (TGL), with NEO 26.18.38308 and libigc 2.34.4+3.
Reproducer
It needs Julia 1.12 and --check-bounds=yes, as the test runner uses:
# julia +1.12 --check-bounds=yes
using oneAPI
x = oneArray(randn(Float32, 100))
findmax(abs, x)
Without --check-bounds=yes it works. The element types the test runner adds don't matter: the failing test uses Float32.
Cause
This is an IGC bug that is already fixed upstream. The first pass of _mapreduce_block! gets a loop whose induction variable increments are turned into llvm.uadd.with.overflow.i64 (OpIAddCarry in the SPIR-V), and IGC's optimizer then folds the extractvalues of two of those calls into a PHI of the whole {i64, i1} struct. IGC's LegalizationPass lowers *.with.overflow intrinsics by replacing their extractvalue users and erasing the call. It only expects extractvalue users (a debug build asserts "Did not expect anything but an extract after uadd_with_overflow"; release builds skip the assertion), so the PHI is left using a deleted instruction. The IGC IR dump after LegalizationPass (IGC_ShaderDumpEnableAll=1) shows phi { i64, i1 } [ <badref>, ... ], and the compiler crashes in a later pass or in free.
The SPIR-V is valid (spirv-val passes). It reproduces offline with ocloc, so the GPU and the driver aren't involved. A reduced kernel:
repro.spvasm
OpCapability Kernel
OpCapability Addresses
OpCapability Int64
%1 = OpExtInstImport "OpenCL.std"
OpMemoryModel Physical64 OpenCL
OpEntryPoint Kernel %kernel "kernel"
OpExecutionMode %kernel ContractionOff
OpSource OpenCL_CPP 100000
%ulong = OpTypeInt 64 0
%bool = OpTypeBool
%void = OpTypeVoid
%15 = OpTypeFunction %void %ulong %bool
%_struct_16 = OpTypeStruct %ulong %ulong
%17 = OpConstantNull %ulong
%ulong_18446744073709551615 = OpConstant %ulong 18446744073709551615
%ulong_1 = OpConstant %ulong 1
%kernel = OpFunction %void None %15
%n = OpFunctionParameter %ulong
%c = OpFunctionParameter %bool
%entry = OpLabel
OpSwitch %n %outer_preheader 0 %exit 1 %exit
%outer_preheader = OpLabel
%23 = OpIAdd %ulong %n %ulong_18446744073709551615
OpBranch %outer
%outer = OpLabel
OpBranchConditional %c %inner_preheader %exit_loopexit1
%inner_preheader = OpLabel
OpBranch %inner
%inner = OpLabel
%24 = OpPhi %ulong %23 %inner_preheader %25 %inner_cont
%26 = OpIAddCarry %_struct_16 %24 %ulong_1
%25 = OpCompositeExtract %ulong %26 0
%27 = OpCompositeExtract %ulong %26 1
%28 = OpINotEqual %bool %27 %17
OpBranchConditional %28 %latch %inner_cont
%inner_cont = OpLabel
OpBranchConditional %c %inner %exit_loopexit
%exit_loopexit = OpLabel
OpBranch %exit
%exit_loopexit1 = OpLabel
OpBranch %exit
%exit = OpLabel
OpReturn
%latch = OpLabel
OpBranch %outer
OpFunctionEnd
$ spirv-as --target-env spv1.4 repro.spvasm -o repro.spv
$ ocloc compile -spirv_input -file repro.spv -device tgllp
Segmentation fault
It crashes with libigc 2.34.4+1, +2 and +3 (so it isn't related to our backports) and with libigc 2.22.2.
Fix
intel/intel-graphics-compiler@522dc7026a6d0b13da721d3364c053b4ee1673b7 ("Add support for non-extract users of llvm.*.with.overflow intrinsics", first in v2.42.0) rebuilds the struct with insertvalue for any user that isn't an extractvalue. Its test covers freeze users, but the change handles PHI users the same way. The patch applies cleanly to v2.34.4, so it could be backported to libigc_jll like #670 and #678, ideally with a LIT test for the PHI case.
- Ngôn ngữ chính
- Julia
- Star
- 217
- Fork
- 37
- Merge trung bình
- 1 ngày 5 giờ
- Pull request đã merge (30 ngày)
- 40
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 JuliaGPU/oneAPI.jl
-
libraries upstream
Độ khó 4/5 1-2 ngày Mức phù hợp với người mới 22/100
JuliaGPU/oneAPI.jl#703 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Make blocking Level Zero calls GC-safeCó thể đã có người làm @maleadt đã nhận 1 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Array construction queries device properties on every allocationCó thể đã có người làm @maleadt đã nhận 1 ngày trước. Đang mở
Độ khó 3/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 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
JuliaGPU/oneAPI.jl#663 · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của JuliaGPU/oneAPI.jl
Issue tương tự
-
Add more snippets to R and JuliaĐang mởenhancement good first issue help wanted
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
SciML/SciMLBase.jl#1643 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
authority-vechtstromen ready-for-agent
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
Deltares/Ribasim-NL#890 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Precompilation fails on Julia 1.14 nightly: HessenbergQ lmul! methods overwrite LinearAlgebra'sĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
JuliaLinearAlgebra/GenericLinearAlgebra.jl#183 · 1 bình luận ·