Open qarmin opened 7 months ago
This could be https://github.com/bytecodealliance/wasmtime/issues/7454. If it is indeed this issue, it is nothing to worry about. Basically the stack probing logic would attempt to write to stack pages to ensure the guard page isn't skipped in case of a stack overflow. Before the fix for that issue it would do the stack probe write before moving the stack pointer, which would result in a write beyond the "red zone". Anything below the red zone can be clobbered by the OS. In this case that would have been fine as it is never read back again, but valgrind doesn't know about this and thus will give an error just in case. The fix swaps the write and the stack pointer adjust such that it will never write beyond the red zone.
A fix for https://github.com/bytecodealliance/wasmtime/issues/7454 will land in the next Cranelift release which will be released at or after the 20th.
Could you try the version at the artifacts section of https://github.com/rust-lang/rustc_codegen_cranelift/actions/runs/6834531001? This is a preliminary update to Cranelift 0.102 with the fixed I mentioned. I can't merge it before the official release though.
Seems to works, Looks that it found(or thinks that found) few issues with unintialized variables
==321048== Conditional jump or move depends on uninitialised value(s)
==321048== at 0x72EAF0A: std_detect::detect::os::detect_features (x86.rs:266)
==321048== by 0x72EA059: std_detect::detect::cache::detect_and_initialize (cache.rs:169)
==321048== by 0x70CA2FE: std_detect::detect::cache::test (cache.rs:193)
==321048== by 0x70CE247: simd_adler32::imp::avx2::get_imp (mod.rs:78)
==321048== by 0x70CA648: core::ops::function::FnOnce::call_once (function.rs:250)
==321048== by 0x70CADBD: core::option::Option<T>::or_else (option.rs:1511)
==321048== by 0x70D1F6B: simd_adler32::imp::get_imp (mod.rs:17)
==321048== by 0x70D20E5: <simd_adler32::Adler32 as core::default::Default>::default (lib.rs:184)
==321048== by 0x70D2036: simd_adler32::Adler32::new (lib.rs:111)
==321048== by 0x70B9149: fdeflate::decompress::Decompressor::new (decompress.rs:181)
==321048== by 0x707F023: png::decoder::zlib::ZlibStream::new (zlib.rs:43)
==321048== by 0x7043F5A: png::decoder::stream::StreamingDecoder::new_with_options (stream.rs:456)
==321048== by 0x7043EF5: png::decoder::stream::StreamingDecoder::new (stream.rs:452)
==321048== by 0x608BD4D: png::decoder::Decoder<R>::new_with_limits (mod.rs:138)
==321048== by 0x60E47B2: image::codecs::png::PngDecoder<R>::with_limits (png.rs:129)
==321048== by 0x60B882D: image::io::free_functions::load_decoder (free_functions.rs:57)
==321048== by 0x60B6838: image::io::free_functions::load_inner (free_functions.rs:113)
==321048== by 0x5E5D1B3: i_slint_core::graphics::image::cache::ImageCache::load_image_from_embedded_data::{{closure}} (free_functions.rs:37)
==321048== by 0x5E5BD62: i_slint_core::graphics::image::cache::ImageCache::lookup_image_in_cache_or_create (cache.rs:66)
==321048== by 0x5E5CCB2: i_slint_core::graphics::image::cache::ImageCache::load_image_from_embedded_data (cache.rs:118)
==321048== by 0x5E5E229: i_slint_core::graphics::image::load_image_from_embedded_data::{{closure}} (image.rs:767)
==321048== by 0x5E410E5: std::thread::local::LocalKey<T>::try_with (local.rs:270)
==321048== by 0x5E3FB1B: std::thread::local::LocalKey<T>::with (local.rs:246)
==321048== by 0x5F56963: i_slint_core::graphics::image::load_image_from_embedded_data (image.rs:766)
==321048== by 0xFDEEA3: krokiet::slint_generatedMainWindow::InnerLeftSidePanel_root_168::init (main_window.rs:1553)
==321048== Uninitialised value was created by a stack allocation
==321048== at 0x72EA5DC: std_detect::detect::os::detect_features (x86.rs:28)
That is a rather large function which depends on inline asm: https://github.com/rust-lang/stdarch/blob/39e37792828c44641b6816ed7b8098b881627a72/crates/std_detect/src/detect/os/x86.rs#L28-L272 I think the origin is line 51 though, where __cpuid(0)
is used to get the vendor id of the cpu. The generated assembly looks correct though. Maybe valgrind thinks cpuid leaves the upper half of the registers undefined and then complains about this?
In any case I can reproduce this using echo 'fn main() { if unsafe { std::arch::x86_64::__cpuid(0).eax } == 0 { println!("foo"); } }' | dist/rustc-clif - -g -O
which produces:
Dump of assembler code for function __inline_asm_rust_out__34c547e5261aeed8_cgu__0_n0:
0x000000000011e324 <+0>: push rbp
0x000000000011e325 <+1>: mov rbp,rsp
0x000000000011e328 <+4>: push rbx
0x000000000011e329 <+5>: mov rbx,rdi
0x000000000011e32c <+8>: mov rax,QWORD PTR [rbx]
0x000000000011e32f <+11>: mov rcx,QWORD PTR [rbx+0x8]
0x000000000011e333 <+15>: mov rsi,rbx
0x000000000011e336 <+18>: cpuid
0x000000000011e338 <+20>: xchg rbx,rsi
0x000000000011e33b <+23>: mov QWORD PTR [rbx+0x10],rsi
0x000000000011e33f <+27>: mov QWORD PTR [rbx],rax
0x000000000011e342 <+30>: mov QWORD PTR [rbx+0x8],rcx
0x000000000011e346 <+34>: mov QWORD PTR [rbx+0x18],rdx
0x000000000011e34a <+38>: pop rbx
0x000000000011e34b <+39>: pop rbp
0x000000000011e34c <+40>: ret
Dump of assembler code for function _ZN8rust_out4main17hdd9be5287a035326E:
0x000000000011e254 <+0>: push rbp
0x000000000011e255 <+1>: mov rbp,rsp
0x000000000011e258 <+4>: sub rsp,0x60
0x000000000011e25c <+8>: lea rsi,[rsp+0x40]
0x000000000011e261 <+13>: mov DWORD PTR [rsi],0x0
0x000000000011e267 <+19>: lea rdi,[rsp+0x48]
0x000000000011e26c <+24>: mov DWORD PTR [rdi],0x0
0x000000000011e272 <+30>: lea rdi,[rsp+0x40]
0x000000000011e277 <+35>: lea rax,[rip+0xa6] # 0x11e324 <__inline_asm_rust_out__34c547e5261aeed8_cgu__0_n0>
0x000000000011e27e <+42>: call rax
0x000000000011e280 <+44>: lea rcx,[rsp+0x50]
0x000000000011e285 <+49>: mov ecx,DWORD PTR [rcx]
0x000000000011e287 <+51>: lea rcx,[rsp+0x40]
0x000000000011e28c <+56>: mov ecx,DWORD PTR [rcx]
0x000000000011e28e <+58>: lea rdx,[rsp+0x48]
0x000000000011e293 <+63>: mov edx,DWORD PTR [rdx]
0x000000000011e295 <+65>: lea rdx,[rsp+0x58]
0x000000000011e29a <+70>: mov edx,DWORD PTR [rdx]
0x000000000011e29c <+72>: test ecx,ecx
=> 0x000000000011e29e <+74>: jne 0x11e31b <_ZN8rust_out4main17hdd9be5287a035326E+199>
[...]
Looks that valgrind again not works for me and I have this message
==22941== Memcheck, a memory error detector
==22941== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==22941== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==22941== Command: ./krokiet
==22941==
==22941== Valgrind: debuginfo reader: ensure_valid failed:
==22941== Valgrind: during call to ML_(img_strdup)
==22941== Valgrind: request for range [465908873, +1) exceeds
==22941== Valgrind: valid image size of 465463512 for image:
==22941== Valgrind: "/home/rafal/Projekty/Rust/czkawka/target/debug/krokiet"
==22941==
==22941== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==22941== Valgrind: I can't recover. Giving up. Sorry.
==22941==
Also I have logs polluted by this messages(I removed entire target folder, but still have such message)
warning: failed to connect to jobserver from environment variable `CARGO_MAKEFLAGS="-j --jobserver-fds=7,8 --jobserver-auth=7,8"`: cannot open file descriptor 7 from the jobserver environment variable value: Bad file descriptor (os error 9)
|
= note: the build environment is likely misconfigured
With cargo build
I don't see this messages
valgrind 3.21.0 - from snap
when using valgrind with default cargo version I not have any problem, but here with cranefild I have this crash