Assertion failure during undefined variable error reporting #57057
Labels
regression
Regression in behavior compared to a previous version
Milestone
Comments
maleadt
added
the
regression
|
This is a CUDA bug, since |
Well, we need it or we deadlock. Could you provide an alternative then, given that we don't have #49933? cc @vchuravy, x-ref JuliaGPU/CUDA.jl#2262 |
|
There is no way to do this that isn't UB, other than to finish implementing #49933 |
giordano
pushed a commit
that referenced
this issue
Feb 15, 2025
This has been bouncing around as a idea for a while. One of the challenges around time-to-safepoint has been Julia code that is calling libraries. Since foreign code will not include safepoints we see increased latency when one thread is running a foreign-call and another wants to trigger GC. The open design question here is: - Do we expose this as an option the user must "opt-in", e.g. by using a keyword arg to `@ccall` or a specific calling-convetion. - Or do we turn this on for all ccall, except for Julia runtime calls. There is relativly little code outside the Julia runtime that needs to be "GC unsafe", exception are programs that directly use the Julia C-API. Incidentially `jl_adopt_thread` and `@cfunction`/`@ccallable` do the right thing and transition to "GC unsafe", regardless of what state the thread currently is in. I still need to figure out how to reliably detect Julia runtime calls, but I think we can switch all other calls to "GC safe". We should also consider optimizations that mark large regions of code without Julia runtime interactions as "GC safe" in particular numeric for-loops. Closes #57057 --------- Co-authored-by: Gabriel Baraldi <[email protected]>
KristofferC
pushed a commit
that referenced
this issue
Feb 15, 2025
This has been bouncing around as a idea for a while. One of the challenges around time-to-safepoint has been Julia code that is calling libraries. Since foreign code will not include safepoints we see increased latency when one thread is running a foreign-call and another wants to trigger GC. The open design question here is: - Do we expose this as an option the user must "opt-in", e.g. by using a keyword arg to `@ccall` or a specific calling-convetion. - Or do we turn this on for all ccall, except for Julia runtime calls. There is relativly little code outside the Julia runtime that needs to be "GC unsafe", exception are programs that directly use the Julia C-API. Incidentially `jl_adopt_thread` and `@cfunction`/`@ccallable` do the right thing and transition to "GC unsafe", regardless of what state the thread currently is in. I still need to figure out how to reliably detect Julia runtime calls, but I think we can switch all other calls to "GC safe". We should also consider optimizations that mark large regions of code without Julia runtime interactions as "GC safe" in particular numeric for-loops. Closes #57057 --------- Co-authored-by: Gabriel Baraldi <[email protected]> (cherry picked from commit 85458a0)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As observed on PkgEval during CUDSS testing: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_date/2025-01/14/CUDSS.primary.log
This is a package that depends on CUDA, which isn't available on PkgEval, so the
libcudaglobal variable as used by the Clang.jl-generatedccalls generates an undefined variable exception. However, that now triggers an assertion:Introduced somewhere in 4250be8...71bfbb3, maybe as part of the binding changes (cc @Keno)?
The text was updated successfully, but these errors were encountered: