Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Kernel launch failures can go unreported

Open
  • Is something wrong?
#535 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
julia
Domain
backend, testing

Research direction

Start by tracing the kernel launch and wait_idle synchronization path described in the issue, then inspect how queue reads and event statuses are handled. The issue suggests retaining recent launch events or making reads wait on them; compare these approaches against the reported PoCL behavior. Done means a launch failure is reported even when a later read succeeds, with a regression test covering that sequence.

Written by the indexing model from the issue text.

Description

runtime

When a kernel fails at launch time, the failure can go unnoticed: a subsequent read returns uninitialized memory and synchronize reports success. Seen with PoCL on Windows, where some SPIR-V kernels only fail to link when they're launched (#534):

using OpenCL, pocl_jll, SIMD

function kernel(out, v)
    out[] = sin(v)
    return
end

v = Vec{16,Float64}(ntuple(Float64, 16))
out = CLArray{Vec{16,Float64},0}(undef)
@opencl kernel(out, v)
println("memory: ", OpenCL.memtype(out))
println("result: ", OpenCL.@allowscalar out[])
println("finish: ", try cl.finish(cl.queue()); "ok" catch err; err end)

JIT session error: Symbols not found: [ _Z7_cl_sinDv16_d ]
JIT session error: Symbols not found: [ _Z7_cl_sinDv16_d ]
memory: OpenCL.cl.UnifiedDeviceMemory
result: <16 x Float64>[1.304637681984e-311, 1.69759663277e-313, 1.304637682079e-311, ...]
finish: ok

When cl.finish directly follows the failed launch, it does throw CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST: wait_idle waits on a marker, and PoCL fails the marker because the command before it failed. But PoCL still executes the read that follows the failed kernel in the in-order queue, and that read completes successfully, so the marker after it does too. The kernel's own event, which carries the error, is never looked at. The spec leaves it to the implementation whether later commands in the queue run after a failure, so we can't rely on the error propagating.

This was confusing while investigating #415: the SIMD tests reported wrong results, and the actual error only showed up as CL_EXEC_STATUS_ERROR_FOR_EVENTS_IN_WAIT_LIST on an unrelated later launch. Options are to keep the event of the last launch(es) per queue and check their status when synchronizing, or to have reads wait on them explicitly.

pocl_jll 7.2.2+0, OpenCL.jl #533, Julia 1.13.1, Windows Server 2022 (VM).

Dominant language
Julia
Stars
313
Forks
50
Avg merge
1d 8h
Merged PRs (30d)
44

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from JuliaGPU/OpenCL.jl

All issues in JuliaGPU/OpenCL.jl

Similar issues

More Julia issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.