error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused

[yurivict]

What type of bug is this?

Other

What subsystems are affected?

Standalone mode

Minimal reproduce step

regular build

What did you expect to see?

n/a

What did you see instead?

error: casting references to a bigger memory layout than the backing allocation is undefined behavior, even if the reference is unused
   --> /wrkdirs/usr/ports/databases/greptimedb/work/RustPython-9ed51374125b5f1a9e5cee5dd7e27023b8591f1e/vm/src/class.rs:124:17
    |
123 |                 let r: &Py<PyType> = &typ;
    |                                       --- backing allocation comes from here
124 |                 &*(r as *const _)
    |                 ^^^^^^^^^^^^^^^^^
    |
    = note: casting from `core::PyRef<type_::PyType>` (8 bytes) to `core::Py<type_::PyType>` (856 bytes)
    = note: `#[deny(invalid_reference_casting)]` on by default

warning: `rustpython-vm` (lib) generated 5 warnings
error: could not compile `rustpython-vm` (lib) due to 1 previous error; 5 warnings emitted

What operating system did you use?

FreeBSD 14.1

What version of GreptimeDB did you use?

0.8.2

Relevant log output and stack trace

Built with rust-nightly-1.80.0.20240507

[tisonkun]

I guess this is the similar to #3656 that we have a old RustPython fork dependency .. but our CI should guard that if you use the same toolchain with the one we configure in rust-toolchain.toml, it should compile.

However, this can be a reason that we rework the Python scripting functions and totally get rid of this debt ..

[yurivict]

#3656 was about the use of discontinued nightly features.

[evenyag]

Is it possible to build with nightly-2024-04-20(1.79.0)?

[yurivict]

Failure occurs with rust-1.79.0

[evenyag]

Failure occurs with rust-1.79.0

Is it rust-nightly?

Looks like that we always depend on the latest rust-nightly package. We don't support 1.80.0 now.
https://github.com/freebsd/freebsd-ports/blob/ce84c5afb89b497aecf69abaf2b7ae34f7ad380c/databases/greptimedb/Makefile#L15-L18

The nightly version of 2024-03-16 is 1.78.0

rustc 1.78.0-nightly (766bdce74 2024-03-16)

But the freebsd package said it is 1.79.0. Not sure if the commit message is correct.
https://www.freshports.org/lang/rust-nightly

1.79.0.20240317

The compiler version we support is rustc 1.79.0-nightly (f9b161492 2024-04-19) and I checked that nightly-2024-03-16 can compile our project. Is it possible to pin the rust-nightly package greptimedb uses to 1.79.0.20240317 and have a try?

[yurivict]

rust-nightly-1.80.0.20240507 fails to build 0.9.0, same error.

[evenyag]

rust-nightly-1.80.0.20240507 fails to build 0.9.0, same error.

This is the latest rust-nightly package.

Looks like that we always depend on the latest rust-nightly package. We don't support 1.80.0 now.

It's expected, we don't support rust-nightly-1.80.0.20240507 now. The RustPython we use doesn't support 1.80.0.

Not sure if we can specify the nightly version in the Makefile

Maybe like this:

BUILD_DEPENDS=	gmake:devel/gmake \
		protoc:devel/protobuf \
		rust-nightly>0:lang/rust-nightly-1.79.0.20240317 \
		${LOCALBASE}/bin/nm:devel/binutils

The root cause is that the freebsd package system can't use the same compiler version we specified in the rust-toolchain.toml. So it might wait until we update the RustPython or remove this dependency. cc @discord9
https://github.com/GreptimeTeam/greptimedb/blob/main/rust-toolchain.toml#L1-L2

[yurivict]

No, in FreeBSD we don't have multiple rust-nightly packages.

[yurivict]

Why don't you just use the stable Rust version?
Why chase some experimental features that get discontinues a short time later?

[discord9]

• The error itself could be related to invalid_reference_casting false positive: dynamically sized types rust-lang/rust#121074 and could be a false positive
• I will upgrade RustPython depend soon, meanwhile you can turn off python feature to build it again once chore: add a compile cfg for python in cmd package #4406 is merged
• or add #[allow(invalid_reference_casting)] to get around it(although it will require patching the depend)
• I failed to create this error with nightly-2024-05-07 in other platform(Ubuntu 22.04.4 LTS, nightly-2024-05-07-x86_64-unknown-linux-gnu) so it could be a platfomr-specified error?)
• Is it possible to show your cmds to reproduce this error?
• Also using nightly because many criticial features is simply not there in stable.... i.e. SIMD port and many other things

Why don't you just use the stable Rust version? Why chase some experimental features that get discontinues a short time later?

[yurivict]

@discord9

0.9.3 still fails to build with the same error.

See the log here with all commands included.

[yurivict]

@discord9

Do you have an idea how can anybody build greptimedb?
When devs build it, what rust version do they use?

I am trying now with a very recent rust-nightly-1.83.0.20241001 and it still fails the same way.

[discord9]

@discord9

Do you have an idea how can anybody build greptimedb? When devs build it, what rust version do they use?

I am trying now with a very recent rust-nightly-1.83.0.20241001 and it still fails the same way.

My toolchain is:

rustc --version
rustc 1.80.0-nightly (72fdf913c 2024-06-05)

I update to:

rustc --version
rustc 1.83.0-nightly (fb4aebddd 2024-09-30)

and still works on ubuntu 22.04
Sorry my mistake for not update this outdated dependence.
This is the cost of using nightly compiler where features and lint can move and change in a incompatible way, but since nightly also contain many useful features we need(i.e. simd) we have to use it, sorry for not update those dependence sooner
I'm to remove this outdated dependency(Rustpython) soon

[yurivict]

No problem!

Please just drop me a line when there is a release with rustpython removed.