udev assertion 'i < num' in device_update_properties_bufs() since 0bd29256 #23150
Labels
needs-reporter-feedback ❓
There's an unanswered question, the reporter needs to answer
sd-device
udev
Comments
|
Maybe, compiler bug? Is it reproducible with a stable version of LLVM? |
yuwata
added
needs-reporter-feedback ❓
|
Reproduced with newer LLVM 7a98d8351b27 (yesterday's HEAD, no notable related changes committed since). Not affected by disabling/enabling fortify and stackprotector. |
|
We've had people hit this in Gentoo with LLVM 14.0.3 and systemd-251-rc2. |
This was referenced Jun 3, 2022
evverx
added a commit
to evverx/systemd
that referenced
this issue
Jun 4, 2022
…_size." This reverts commit 0bd2925. Unlike __builtin_object_size, __builtin_dynamic_object_size is called at runtime and it isn't guaranteed anywhere that it always works with every pointer passed to it. It currently works with gcc because it returns -1 most of the time (which means that malloc_usable_size is used more often than not) but with clang (and probably gcc in the foreseeable future) it's just not safe to assume that all pointers can be handled at runtime. Closes systemd#23619 and systemd#23150. Reopens systemd#22801
evverx
added a commit
to evverx/systemd
that referenced
this issue
Jun 4, 2022
…_size." This reverts commit 0bd2925. Unlike __builtin_object_size, __builtin_dynamic_object_size is called at runtime and it isn't guaranteed anywhere that it always works with every pointer passed to it. It currently works with gcc because it returns -1 most of the time (which means that malloc_usable_size is used more often than not) but with clang (and probably gcc in the foreseeable future) it's just not safe to assume that all pointers can be handled at runtime. Closes systemd#23619 and systemd#23150. Reopens systemd#22801
evverx
added a commit
to evverx/systemd
that referenced
this issue
Jun 5, 2022
…_size." This reverts commit 0bd2925. Unlike __builtin_object_size, __builtin_dynamic_object_size is called at runtime and it isn't guaranteed anywhere that it always works with every pointer passed to it. It currently works with gcc because it returns -1 most of the time (which means that malloc_usable_size is used more often than not) but with clang (and probably gcc in the foreseeable future) it's just not safe to assume that all pointers can be handled at runtime. Closes systemd#23619 and systemd#23150. Reopens systemd#22801
evverx
added a commit
to evverx/systemd
that referenced
this issue
Jun 5, 2022
…_size." This reverts commit 0bd2925. It isn't guaranteed anywhere that __builtin_dynamic_object_size can always deduce the size of every object passed to it so systemd can end up using either malloc_usable_size or __builtin_dynamic_object_size when pointers are passed around, which in turn can lead to actual segfaults like the one mentioned in systemd#23619. Apparently __builtin_object_size can return different results for pointers referring to the same memory as well but somehow it hasn't caused any issues yet. Looks like this whole malloc_usable_size/FORTIFY_SOURCE stuff should be revisited. Closes systemd#23619 and systemd#23150. Reopens systemd#22801
|
I'm not sure why GitHub didn't close it automatically. It was fixed by reverting that patch in #23621. Closing. |
bluca
pushed a commit
to bluca/systemd-stable
that referenced
this issue
Nov 7, 2022
…_size." This reverts commit 0bd2925. It isn't guaranteed anywhere that __builtin_dynamic_object_size can always deduce the size of every object passed to it so systemd can end up using either malloc_usable_size or __builtin_dynamic_object_size when pointers are passed around, which in turn can lead to actual segfaults like the one mentioned in systemd/systemd#23619. Apparently __builtin_object_size can return different results for pointers referring to the same memory as well but somehow it hasn't caused any issues yet. Looks like this whole malloc_usable_size/FORTIFY_SOURCE stuff should be revisited. Closes systemd/systemd#23619 and systemd/systemd#23150. Reopens systemd/systemd#22801 (cherry picked from commit 2cfb790)
bluca
pushed a commit
to systemd/systemd-stable
that referenced
this issue
Nov 7, 2022
…_size." This reverts commit 0bd2925. It isn't guaranteed anywhere that __builtin_dynamic_object_size can always deduce the size of every object passed to it so systemd can end up using either malloc_usable_size or __builtin_dynamic_object_size when pointers are passed around, which in turn can lead to actual segfaults like the one mentioned in systemd/systemd#23619. Apparently __builtin_object_size can return different results for pointers referring to the same memory as well but somehow it hasn't caused any issues yet. Looks like this whole malloc_usable_size/FORTIFY_SOURCE stuff should be revisited. Closes systemd/systemd#23619 and systemd/systemd#23150. Reopens systemd/systemd#22801 (cherry picked from commit 2cfb790)
Yamakuzure
pushed a commit
to elogind/elogind
that referenced
this issue
Dec 23, 2022
…_size." This reverts commit 0bd292567a543d124cd303f7dd61169a209cae64. It isn't guaranteed anywhere that __builtin_dynamic_object_size can always deduce the size of every object passed to it so systemd can end up using either malloc_usable_size or __builtin_dynamic_object_size when pointers are passed around, which in turn can lead to actual segfaults like the one mentioned in systemd/systemd#23619. Apparently __builtin_object_size can return different results for pointers referring to the same memory as well but somehow it hasn't caused any issues yet. Looks like this whole malloc_usable_size/FORTIFY_SOURCE stuff should be revisited. Closes systemd/systemd#23619 and systemd/systemd#23150. Reopens systemd/systemd#22801
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
systemd version the issue has been seen with
Bisected to 0bd2925
Used distribution
Debian Unstable
Linux kernel version used (
uname -a)Linux v11.cleveronmobility.dev 5.16.0-6-amd64 #1 SMP PREEMPT Debian 5.16.18-1 (2022-03-29) x86_64 GNU/LinuxCPU architecture issue was seen on
amd64
Expected behaviour you didn't see
Sucessful startup
Unexpected behaviour you saw
An assertion. As a result drivers necessary for the internal disk aren't loaded during initramfs and the system fails to boot.
Steps to reproduce the problem
Boot latest systemd master on PC Engines APU2
Additional program output to the terminal or log subsystem illustrating the issue
Full boot log with
udev.log-priority=debugAdditional details
Compiled using LLVM aed0e8b8056a with
-march=ivybridge.I built systemd with Debian tools and mostly downstream Debian patches. I'm hesitant to blame those at first as the offending commit seems innocuous.
Will try building with the latest LLVM head soon. Happy to provide any further information or help with debugging.
The text was updated successfully, but these errors were encountered: