poky-patched cargo segfaults on cargo build --bin helloworld
#128492
Comments
Yashinde145
added
C-bug
rustbot
added
the
needs-triage
I don't know what this means. How can we reproduce what you are doing? Can you maybe create a repository that reproduces your issue? |
oli-obk
added
E-needs-mcve
|
Sure, I will create a repo and share the link here in sometime. |
|
looks like incr comp bug? :/ |
|
Here is the link for the repo, https://github.com/Yashinde145/Cargo_seg_fault_1_79 Steps to reproduce the seg fault:
The following error logs will be seen: After this the above mention backtrace is seen. |
|
All of the changes in the yocto patches seem like they are designed to make it more likely that an incremental compilation failure occurs by
This does not mean "yocto did it". But it is harder to see what did. @Yashinde145 Your problem would be significantly easier to diagnose if this build system at least guaranteed sufficient symbol tables and/or frame-pointers in the build dependencies so that we get back a full backtrace to work with. All I can guess from here is that you should set |
|
https://github.com/Yashinde145/Cargo_seg_fault_1_79/blob/c6956f2339e5b30d8ae00a23377e5ed7117f47e9/meta/recipes-devtools/rust/files/0001-cargo-do-not-write-host-information-into-compilation.patch from a cursory look at your patches, this one seems really suspicious. it doesn't just remove the host, it also removes the rustc version. so maybe you're getting overlapping build directories for different rustc versions somewhere, which is guaranteed to cause crashes? |
|
It would be useful to know if it still ceashes without these patches. |
|
Does this actually need to be Why isn't It would be nice if this reproducer was turnkey. As in one command. Not "source this, write this conf file, then run this build command, and still have no idea how to inject environment variables into a build system that is deliberately trying to be impervious to external settings, without reading a treatise about 'layers' and how much I would absolutely love them if I was building a custom distribution for SBCs." |
The commit Yashinde145/Cargo_seg_fault_1_79@c6956f2 does increment rust version updates from v1.75 to v1.79 which includes:
Agreed. Even I guess |
The issue is seen when running
I will try to share the reproducer with a bash script in a while. |
|
@Yashinde145 making binaries more "reproducible" by making them look more similar to each other, when those differences are often what rustc and cargo use to prevent compiling and linking code that is not ABI-compatible, is dangerous. And this patch unconditionally disables a check instead of unconditionally enabling it. Which means rustc no longer checks if it can produce correct code, ever: yoctoproject/poky@c08c522 Do you see the problem with yocto repeatedly simply disabling safety checks in the name of "reproducibility", and then filing bugs against rustc? Why is yocto waiting until they've busted the compiler's output instead of asking how the compiler can be patched to make something more reproducible? |
Yes, I will check by reverting the |
I am not sure what's the actual cause here. |
|
Reproducer script: |
|
Does this reproduce with the latest rustc nightly and all obsolete patches dropped? Half the patches seem to be obsolete and for some of them the original patch is not entirely correct I think. |
|
I updated the script to be repeatable from the root of the repository: #!/bin/bash
# Exit immediately if a command exits with a non-zero status
set -e
# Source the OE build environment
source oe-init-build-env
# Define the local.conf file path
LOCAL_CONF_FILE="conf/local.conf"
local_conf_setup="$(grep "$LOCAL_CONF_FILE" -e 'TOOLCHAIN')"
# Append necessary configurations to local.conf
if [ "$local_conf_setup" ]; then
echo "Already set up conf file..."
else
echo 'TOOLCHAIN_TARGET_TASK = "cargo rust"' >> $LOCAL_CONF_FILE
echo 'TOOLCHAIN_HOST_TASK:append = " packagegroup-rust-cross-canadian-${MACHINE}"' >> $LOCAL_CONF_FILE
echo 'TOOLCHAIN_TARGET_TASK:append = " libstd-rs"' >> $LOCAL_CONF_FILE
echo 'IMAGE_CLASSES += "testimage testsdk"' >> $LOCAL_CONF_FILE
echo 'TESTIMAGE_AUTO:qemuall = "1"' >> $LOCAL_CONF_FILE
echo 'SANITY_TESTED_DISTROS=""' >> $LOCAL_CONF_FILE
fi
# Run the bitbake command
bitbake core-image-sato -c do_testsdkI then removed a number of patches, including the "
@Yashinde145 Please remove the I do not think we can help you further with your problems until that is done. |
workingjubilee
added
C-gub
workingjubilee
changed the title
poky-patched cargo segfaults on cargo build --bin helloworld
workingjubilee
added
the
I-crash
|
Update for:
and
I did both the changes and still get the same error. |
|
@workingjubilee ,
I will make the commit changes as suggested by you I will update here once I have the changes ready. |
cargo buildfor a simple hello world program gives seg fault when built in sdk environment using poky sources.This was first observed in rustc v1.78 and continued in v1.79 and v1.80 also.
(Note: There's no change in the process of sdk build env when tested between the versions).
rustc --version --verbose:Error output
The backtrace generated is same for with "RUST_BACKTRACE=1" and "RUST_BACKTRACE=full".
I suspect the following out of bounds index access is the main reason for seg fault here.
at compiler/rustc_metadata/src/creader.rs:193:31:
index out of bounds: the len is 20 but the index is 60747757fbc9b94 and 0025c9c are the recent commits related to this.
Maybe @oli-obk can help to understand the error better?
Backtrace
The text was updated successfully, but these errors were encountered: