Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

IGC heap corruption compiling findmax's reduction kernel on Julia 1.12 with --check-bounds=yes

已关闭
  • 哪里不对？
#691 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
领域
compilers

调研方向

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.

由索引模型根据 Issue 内容生成。

描述

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.

主要语言
Julia
星标
218
派生
36
平均合并
1 天 6 小时
30 天内合并 PR
65

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

JuliaGPU/oneAPI.jl 的其他 Issue

查看 JuliaGPU/oneAPI.jl 的全部 Issue

相似的 Issue

更多 Julia Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。