Segmentation fault in Julia v1.11.4 due to unaligned SIMD loads #57713
Labels
Comments
|
Curiously, this issue does not occur with Note that |
|
What is |
|
@vchuravy I'm on Linux x86-64 using an AMD Ryzen 9 9950X CPU (Zen 5 microarchitecture). Full info below: |
|
#56938 had to be reverted from the backport list to 1.11 and 1.10 because it caused other failures (in the VecElement tests). I will open backports for the new version and include it and the test error can be investigated. |
|
@KristofferC Got it, thanks! In that case, I'll keep using v1.10 for now and hold off until the next v1.11 release to port MultiFloats.jl and the rest of my code over. |
|
Possibly related to (duplicate of?) #56265 |
|
I actually get julia> @noinline function bar32414(a)
v = ntuple(w -> VecElement(Float64(10w)), Val(8))
return a, (v, (a, (1e6, 1e9)))
end
bar32414 (generic function with 1 method)
julia> bar32414(-35.0)
Assertion failed: (SL->getElementOffset(idx) == byte_offset), function convert_struct_offset, file cgutils.cpp, line 608.
[29361] signal 6: Abort trap: 6
in expression starting at REPL[2]:1
__pthread_kill at /usr/lib/system/libsystem_kernel.dylib (unknown line)
Allocations: 1932943 (Pool: 1932489; Big: 454); GC: 3
[1] 29361 abort ./juliaon the 1.11 backport branch with the alignment fix in it. @gbaraldi, any idea? |
|
Digging into this more, there's a weird plot twist: I previously thought the cause was Julia v1.11 having weaker alignment guarantees than v1.10, but that's not the whole story. It turns out But here's the kicker: Julia v1.10 was smart enough to generate an unaligned load! So, there is indeed a regression in Julia v1.11, but it's not the one I thought it was. For some reason we started erroneously generating an aligned load where we used to correctly generate an unaligned load. |
vtjnash
added a commit
that referenced
this issue
Mar 11, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset. This can be strongly counter-intuitive (as it implies adding padding where it does not seem to provide value), but is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment)
vtjnash
added a commit
that referenced
this issue
Mar 11, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset. This can be strongly counter-intuitive (as it implies adding padding where it does not seem to provide value), but is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment)
KristofferC
pushed a commit
that referenced
this issue
Mar 11, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment)
vtjnash
added a commit
that referenced
this issue
Mar 12, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (Cherry-picked from c9008ff, with typo fix to typed_loaded memcpy which was already deleted from master)
vtjnash
added a commit
that referenced
this issue
Mar 12, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (Cherry-picked from ec3c02a in v1.11 backports branch)
|
@dzhang314, can you try this now on the 1.11 backport branch? #57714 |
|
@KristofferC Sorry about the delay on my end -- it looks good now! The initially problematic code now runs fine, and I suppose this means I can expect a fix in v1.11.5. Should I go ahead and close this issue now, or wait until v1.11.5 is released? |
KristofferC
pushed a commit
that referenced
this issue
Mar 20, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (cherry picked from commit c9008ff)
KristofferC
pushed a commit
that referenced
this issue
Mar 25, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (Cherry-picked from c9008ff, with typo fix to typed_loaded memcpy which was already deleted from master)
KristofferC
pushed a commit
that referenced
this issue
Mar 31, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (Cherry-picked from ec3c02a in v1.11 backports branch)
KristofferC
pushed a commit
that referenced
this issue
Mar 31, 2025
The alignment of a nested object (in C layouts) is not affected by the alignment of its parent container when computing a field offset (as if it will be allocated at address 0). This can be strongly counter-intuitive (as it implies it should add padding where it does not seem to provide value to the user), but this is required to match the C standard. It also permits users to write custom allocators which happen to provide alignment in excess of that which codegen may assume is guaranteed, and get the behavioral characteristics they intended to specify (without resorting to computing explicit padding). Addresses #57713 (comment) (Cherry-picked from ec3c02a in v1.11 backports branch)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a serious regression in Julia v1.11 that makes it completely unusable for my applications built on top of SIMD.jl + MultiFloats.jl. I think it was supposed to be fixed in #56937 and #56938, but I still observe the issue in v1.11.4.
If we have a
structwith a member of typeNTuple{N,VecElement{T}}, reading that struct member from memory generates an aligned vector load instruction. This is a serious problem because allocations are no longer 64-byte-aligned in Julia v1.11, and AVX-512 loads segfault if the target address is not 64-byte aligned. This makes it impossible to work with these structs, which badly breaks SIMD.jl. We cannot even print them:Here, I'm performing 10 trials to be conservative -- on my machine, I always get a segfault in the first 3-4 tries. We can see the problematic load instruction using
code_native:Either that
vmovapsneeds to be avmovups, or all allocations need to be 64-byte-aligned again.The text was updated successfully, but these errors were encountered: