make check-functional failures with --enable-rust: unsafe precondition(s) violated: NonNull::new_unchecked

make check-functional failures with --enable-rust: unsafe precondition(s) violated: NonNull::new_unchecked

[Peter Maydell]

I noticed that 'make check-functional' for arm targets doesn't all
pass when QEMU is built with --enable-rust:

11/46 qemu:func-thorough+func-aarch64-thorough+thorough /
func-aarch64-aarch64_virt            TIMEOUT         720.03s   killed
by signal 15 SIGTERM
 9/46 qemu:func-thorough+func-arm-thorough+thorough /
func-arm-arm_tuxrun                      ERROR            51.71s
exit status 1
30/46 qemu:func-thorough+func-arm-thorough+thorough /
func-arm-arm_vexpress                    ERROR             1.62s
exit status 1
44/46 qemu:func-thorough+func-arm-thorough+thorough /
func-arm-arm_replay                      TIMEOUT          90.02s
killed by signal 15 SIGTERM

The first of these is the virt/gpu breakage that's not Rust related.

tuxrun fails because of a Rust panic, though:

        Command:
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/rust/qemu-system-arm
-display none -vga none -chardev socket,id=mon,fd=5 -mon
chardev=mon,mode=control -machine versatilepb -chardev
socket,id=console,fd=10 -serial chardev:console -cpu arm926 -kernel
/home/petmay01/.cache/qemu/download/3931a3908dbcf0ec0fe292d035ffc4dfed95f797dedd4a59ccfcf7a46e6f92d4
-append printk.time=0 root=/dev/vda console=ttyAMA0 -blockdev
driver=raw,file.driver=file,file.filename=/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/rust/tests/functional/arm/test_arm_tuxrun.TuxRunArmTest.test_armv5/scratch/60ff78b68c7021df378e4fc2d66d3b016484d1acc7e07fb8920c1d8e30f4571f,node-name=hd0
-device virtio-blk-pci,drive=hd0 -dtb
/home/petmay01/.cache/qemu/download/50988e69ef3f3b08bfb9146e8fe414129990029e8dfbed444953b7e14809530a
        Output: thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
unsafe precondition(s) violated: NonNull::new_unchecked requires that
the pointer is non-null
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread caused non-unwinding panic. aborting.

and the vexpress and replay failures are the same panic.

Is this a known issue ? (I'm using git commit 98c7362b1efe.)

Here's the RUST_BACKTRACE=1 version:

thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
unsafe precondition(s) violated: NonNull::new_unchecked requires that
the pointer is non-null
stack backtrace:
   0: rust_begin_unwind
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:662:5
   1: core::panicking::panic_nounwind_fmt::runtime
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:112:18
   2: core::panicking::panic_nounwind_fmt
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:122:5
   3: core::panicking::panic_nounwind
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:221:5
   4: core::ptr::non_null::NonNull<T>::new_unchecked::precondition_check
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ub_checks.rs:70:21
   5: core::ptr::non_null::NonNull<T>::new_unchecked
             at
/rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ub_checks.rs:77:17
   6: qemu_api::qom::Owned<T>::from
             at ./rust/qemu-api/libqemu_api.rlib.p/structured/qom.rs:741:19
   7: pl011_create
             at ./../../rust/hw/char/pl011/src/device.rs:716:24
   8: vexpress_common_init
             at ./../../hw/arm/vexpress.c:647:5
   9: machine_run_board_init
             at ./../../hw/core/machine.c:1682:5
  10: qemu_init_board
             at ./../../system/vl.c:2711:5
  11: qmp_x_exit_preconfig
             at ./../../system/vl.c:2807:5
  12: qemu_init
             at ./../../system/vl.c:3843:9
  13: main
             at ./../../system/main.c:68:5
  14: __libc_start_call_main
             at ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
  15: __libc_start_main_impl
             at ./csu/../csu/libc-start.c:360:3
  16: _start

(side note: should we set RUST_BACKTRACE=1 for our
make check/check-functional infra? it would probably be better
to capture the backtrace in the logfiles rather than needing
the user to re-run by hand, especially for the CI case.)

thanks
-- PMM

Re: make check-functional failures with --enable-rust: unsafe precondition(s) violated: NonNull::new_unchecked

[Peter Maydell]

On Fri, 7 Mar 2025 at 18:24, Peter Maydell <peter.maydell@linaro.org> wrote:
> thread '<unnamed>' panicked at core/src/panicking.rs:221:5:
> unsafe precondition(s) violated: NonNull::new_unchecked requires that
> the pointer is non-null
> stack backtrace:
>    0: rust_begin_unwind
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/std/src/panicking.rs:662:5
>    1: core::panicking::panic_nounwind_fmt::runtime
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:112:18
>    2: core::panicking::panic_nounwind_fmt
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:122:5
>    3: core::panicking::panic_nounwind
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/panicking.rs:221:5
>    4: core::ptr::non_null::NonNull<T>::new_unchecked::precondition_check
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ub_checks.rs:70:21
>    5: core::ptr::non_null::NonNull<T>::new_unchecked
>              at
> /rustc/f6e511eec7342f59a25f7c0534f1dbea00d01b14/library/core/src/ub_checks.rs:77:17
>    6: qemu_api::qom::Owned<T>::from
>              at ./rust/qemu-api/libqemu_api.rlib.p/structured/qom.rs:741:19
>    7: pl011_create
>              at ./../../rust/hw/char/pl011/src/device.rs:716:24
>    8: vexpress_common_init
>              at ./../../hw/arm/vexpress.c:647:5

The backtrace suggests that the rust version of pl011_create()
isn't able to handle being passed in a NULL chr. This is
permitted and means "don't connect up a chardev to the device's
chr property" which in turn means "you don't have a chardev
backend" (and all the C qemu_chr_fe_* functions happily accept
NULL and interpret it as "just do nothing").

-- PMM

Re: make check-functional failures with --enable-rust: unsafe precondition(s) violated: NonNull::new_unchecked

[Philippe Mathieu-Daudé]

On 7/3/25 19:24, Peter Maydell wrote:
> I noticed that 'make check-functional' for arm targets doesn't all
> pass when QEMU is built with --enable-rust:
> 
> 11/46 qemu:func-thorough+func-aarch64-thorough+thorough /
> func-aarch64-aarch64_virt            TIMEOUT         720.03s   killed
> by signal 15 SIGTERM
>   9/46 qemu:func-thorough+func-arm-thorough+thorough /
> func-arm-arm_tuxrun                      ERROR            51.71s
> exit status 1
> 30/46 qemu:func-thorough+func-arm-thorough+thorough /
> func-arm-arm_vexpress                    ERROR             1.62s
> exit status 1
> 44/46 qemu:func-thorough+func-arm-thorough+thorough /
> func-arm-arm_replay                      TIMEOUT          90.02s
> killed by signal 15 SIGTERM
> 
> The first of these is the virt/gpu breakage that's not Rust related.
> 
> tuxrun fails because of a Rust panic, though:

[...]

> Is this a known issue ? (I'm using git commit 98c7362b1efe.)
> 
> Here's the RUST_BACKTRACE=1 version:


> (side note: should we set RUST_BACKTRACE=1 for our
> make check/check-functional infra? it would probably be better
> to capture the backtrace in the logfiles rather than needing
> the user to re-run by hand, especially for the CI case.)

I agree, and Stefan also suggested that:
https://lore.kernel.org/qemu-devel/CAJSP0QWJ=qkA2Bzih7nGq5K=YrJRqUOt85RAGL=mj3MEjAW6ug@mail.gmail.com/