.rodata wrong with rust

[limuy2022]

When I use it with rustc.And I tried valgrind to run the program.The valgrind will report error:

Can't make sense of .rodata section mapping

After I switch to the default linker,it works well note:I try a smallest rust project but it still have this problem I am using archlinux and mold 2.30.0,rust nightly version

[rui314]

What is your valgrind version? IIRC, valgrind recently made a change so that they are compatible with mold's output.

[limuy2022]

the version is 3.22.0,the latest version

[limuy2022]

in addition，when i use cranelift backend instead of llvm backend.the mold caused another error:

valgrind: debuginfo reader: possibly corrupted debuginfo file

[rui314]

What is your program? I need to reproduce your issue locally to see what's going on.

[limuy2022]

error.zip in fact,use any rust program with the config.toml in it can reproduce this error

use the following in config.toml can cause the second error

# [unstable]
# codegen-backend = true
#
# [profile.dev]
# codegen-backend = "cranelift"

[rui314]

It works for me. I ran it on Ubuntu 24.04 on Docker.

$ readelf -p .comment target/debug/rust_real_test

String dump of section '.comment':
  [     0]  GCC: (Ubuntu 13.2.0-23ubuntu4) 13.2.0
  [    26]  mold 2.30.0 (aae3b43092ab5e6ae79613e7fae7539c9402e713; compatible with GNU ld)
  [    76]  rustc version 1.77.2 (25ef9e3d8 2024-04-09)

$ valgrind --leak-check=full target/debug/rust_real_test
==8783== Memcheck, a memory error detector
==8783== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==8783== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==8783== Command: target/debug/rust_real_test
==8783==
Value: "hello"
==8783==
==8783== HEAP SUMMARY:
==8783==     in use at exit: 0 bytes in 0 blocks
==8783==   total heap usage: 11 allocs, 11 frees, 3,181 bytes allocated
==8783==
==8783== All heap blocks were freed -- no leaks are possible
==8783==
==8783== For lists of detected and suppressed errors, rerun with: -s
==8783== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

$ valgrind --version
valgrind-3.22.0

[limuy2022]

I cannot reproduce it in debian 12,either.Please keep this issue on,I am a senior high school student and I cannot try finding the problem until the next week.Thank you

[limuy2022]

I found a way to reproduce this issue.By compiling my toy compiler(sorry,other simple rust program cannot reproduce it), using rust cranelift(without cranelift will work well,but only use cranelift can works well,too.so I cannot determine mold and cranelift which caused this issue) and mold can do it by the following steps. 1.Clone my toy compiler 2.Install cranelift 3.use the following config.toml

[unstable]
codegen-backend = true

[profile.dev]
codegen-backend = "cranelift"
[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "link-arg=-fuse-ld=mold", "-Z", "threads=8"]

[target.'cfg(target_os = "linux")']
runner = "valgrind --leak-check=full"

4.run cargo build --all 5.run cargo test --all 6.then you can reproduce it in some of the unittest Sorry,but I really cannot reproduce it in simple rust program. Error message:

==947486== Memcheck, a memory error detector
==947486== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==947486== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info
==947486== Command: /home/limuy/trc/target/debug/deps/libcore-e936353cf2358c7f
==947486== 
==947486== Valgrind: debuginfo reader: ensure_valid failed:
==947486== Valgrind:   during call to ML_(img_strdup)
==947486== Valgrind:   request for range [36949181, +1) exceeds
==947486== Valgrind:   valid image size of 36802224 for image:
==947486== Valgrind:   "/home/limuy/trc/target/debug/deps/libcore-e936353cf2358c7f"
==947486== 
==947486== Valgrind: debuginfo reader: Possibly corrupted debuginfo file.
==947486== Valgrind: I can't recover.  Giving up.  Sorry.
==947486== 

[limuy2022]

If it also doesn't report this error.Try using the dev branch.In my environment,both of them will report the error

[rui314]

Can you upload your executable file that valgrind reported issue with?

[limuy2022]

oh,ok ok.I forgot it. wrong_exe.zip

[rui314]

I think the executable is not really broken, but it looks like Valgrind just assumes something different. Please report it to Valgrind.

[limuy2022]

Ok.I will report it to valgrind soon

[rui314]

Was it solved upstream?

[limuy2022]

No,I am still waiting for the response.Should I reopen this issue?

[rui314]

No, but I'd like you to paste the link to the upstream bug here for the sake of tracking purposes.

[paulfloyd]

the version is 3.22.0,the latest version

Not any more. 3.23 has been released. Can you try that?

This sounds very much like bugzi 478837.

[limuy2022]

Almost the same question,however,I tried the valgrind 3.23,this problem still here

[paulfloyd]

Almost the same question,however,I tried the valgrind 3.23,this problem still here

Bah.

https://bugs.kde.org/show_bug.cgi?id=486538

[paulfloyd]

I'm not able to reproduce this on FreeBSD.

Please can you do the following:

1. run objdump -p on your exacutable and post the PT_LOAD segments, which should look something like

    LOAD off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**12
         filesz 0x0000000000016580 memsz 0x0000000000016580 flags r--
    LOAD off    0x0000000000016580 vaddr 0x0000000000017580 paddr 0x0000000000017580 align 2**12
         filesz 0x000000000004092c memsz 0x000000000004092c flags r-x
    LOAD off    0x0000000000056eb0 vaddr 0x0000000000058eb0 paddr 0x0000000000058eb0 align 2**12
         filesz 0x0000000000002ef8 memsz 0x0000000000003150 flags rw-
    LOAD off    0x0000000000059da8 vaddr 0x000000000005cda8 paddr 0x000000000005cda8 align 2**12
         filesz 0x0000000000000080 memsz 0x0000000000000160 flags rw-

2. Run objdump -h on your exe and pipe it through a grep for rodata e.g.

objdump -h target/debug/rust_real_test | grep rodata 14 .rodata 00005dd4 0000000000010410 DATA 16 .rodata.str1.1 00000001 0000000000016206 DATA 17 .rodata.cst4 0000004c 0000000000016208 DATA 18 .rodata.cst8 00000040 0000000000016258 DATA 19 .rodata.cst16 00000260 00000000000162a0 DATA 20 .rodata.cst32 00000080 0000000000016500 DATA

3. run Valgrind -d -d -d on your exe. The output will be very long. I'm only interested in the but releated to reading your exe's elf segments which should look like this

--6368-- di_notify_mmap-0: --6368-- di_notify_mmap-1: 0x108000-0x11efff r-- --6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test --6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 0, is_ro_map 1 --6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024 --6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128 --6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220 --6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping) --6368-- di_notify_mmap-0: --6368-- di_notify_mmap-1: 0x11f000-0x15ffff r-x --6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test --6368-- di_notify_mmap-3: is_rx_map 1, is_rw_map 0, is_ro_map 0 --6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024 --6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128 --6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220 --6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping) --6368-- di_notify_mmap-0: --6368-- di_notify_mmap-1: 0x160000-0x163fff rw- --6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test --6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0 --6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024 --6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128 --6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220 --6368-- di_notify_mmap-6: no dinfo loaded /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test (no rx or no rw mapping) --6368-- di_notify_mmap-0: --6368-- di_notify_mmap-1: 0x164000-0x164fff rw- --6368-- di_notify_mmap-2: /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test --6368-- di_notify_mmap-3: is_rx_map 0, is_rw_map 1, is_ro_map 0 --6368-- check_elf_and_get_rw_loads: ++*rw_load_count to 1 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x58eb0 p_offset 356016, p_filesz 12024 --6368-- check_elf_and_get_rw_loads: ++rw_load_count to 2 for /usr/home/paulf/scratch/vg_examples/bug486538/target/debug/rust_real_test p_vaddr 0x5cda8 p_offset 368040, p_filesz 128 --6368-- di_notify_mmap-4: noting details in DebugInfo at 0x100287C220

4. Post the output of valgrind --version

[paulfloyd]

oh,ok ok.I forgot it. wrong_exe.zip

[paulf@archlinux bug]$ valgrind ./wrong_exe ==23348== Memcheck, a memory error detector ==23348== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==23348== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info ==23348== Command: ./wrong_exe ==23348== ==23348== Valgrind: debuginfo reader: ensure_valid failed: ==23348== Valgrind: during call to ML_(img_strdup) ==23348== Valgrind: request for range [36949181, +1) exceeds ==23348== Valgrind: valid image size of 36802224 for image: ==23348== Valgrind: "/home/paulf/bug/wrong_exe" ==23348== ==23348== Valgrind: debuginfo reader: Possibly corrupted debuginfo file. ==23348== Valgrind: I can't recover. Giving up. Sorry.

This is a completely different error to the one that has been fixed that you described initially,

[paulfloyd]

dwarfdump -ka also complains

*** DWARF CHECK: .debug_ranges: Address outside a valid .text range ***

As far as I'm concerned this is not a Valgrind issue. The problem is either with rust or with mold.

I've closed the upstream bug.

[limuy2022]

but this file make valgrind report the same issue on Debian.I cannot determine.

[paulfloyd]

You need to find which tool is responsible for writing incorrect debuginfo. The problem doesn't seem to be in Valgrind.

[rui314]

@paulfloyd I didn't get that error when I run dwarfdump -ka wrong_exe on my machine. Did you run it against the file that @limuy2022 uploaded or something else?

[paulfloyd]

I greatly truncated the output. The .debug_ranges message is there something like 13k times.

On Arch Linux in VirtualBox Static hostname: archlinux Icon name: computer-vm Chassis: vm ���� Machine ID: 67a31487732e497ea5240c91dea76001 Boot ID: 9091880bdacc4d50b3174d22d135f797 Virtualization: oracle Operating System: Arch Linux
Kernel: Linux 6.8.9-arch1-1 Architecture: x86-64 Hardware Vendor: innotek GmbH Hardware Model: VirtualBox Firmware Version: VirtualBox Firmware Date: Fri 2006-12-01 Firmware Age: 17y 5month 1w 3d

dwarfdump --version dwarfdump [Apr 5 2024 09:24:43 (libdwarf 0.9.2 dwarfdump 0.9.2)]

[rui314]

@limuy2022 I'm still struggling to reproduce your problem. mold has a nice feature to pack all the input files and command line options into a single tar file so that anyone can run mold with the exact same inputs. Can you add -repro to the linker flag, compile your code and then share the generated tar file? That should make reproducing your issue extremely easy.

[limuy2022]

@paulfloyd I think maybe because you are on archlinux so that you can't reproduce this issue.I can't on archlinux,too.But it can be reproduced on debian(maybe ubuntu) @rui314 I will try that later

[limuy2022]

I tried add this flag,but there is not any tar file generated.Sorry about letting you waiting for such a long time.

[rui314]

Can't you find it with find . -name '*.tar"?