!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

651 Members
Rust147 Servers

Load older messages

SenderMessageTime
11 Jul 2025
@tomasajt:matrix.orgTomaOh wow, this info is outdated. I guess this part of the docs was not updated when we removed fetchCargoTarball With the new fetcher there is no difference in the hash, even if you use a different name/version or whatever. (Note: cargoDepsName does not do anything currently as far as I'm aware)01:30:40
@setthemfree:matrix.orgundltd I see, I suspected there might have been a recent change. It does seem to change the name of some intermediate derivation, but doesn't look like it affects the hash.

Do I understand correctly that cargoHash depends not only on the tarball of vendored dependencies, but also on the (hash of) Cargo.lock? 		06:18:16
@sodiboo:gaysex.cloudsodiboo joined the room.07:12:29
@cpick:matrix.orgcpick

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
Hello, world!
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}
17:25:25
@cpick:matrix.orgcpick *

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}
17:26:39
@cpick:matrix.orgcpick *

I'm trying to get a debugger to stop at a breakpoint when my rust program panics. I understand the recommendation to be to break on the rust_panic() function, but that's not working for me. Does anyone have any experience with this (or have an alternative)?

I'm on aarch64, I've tried both darwin and NixOS linux (via VM) both using nixpkgs cargo, rustc, lldb and gdb packages.

I've tried both rust-lldb and rust-gdb, neither is able to find the function and neither hit the breakpoint:

$ rust-lldb target/debug/delme
...
(lldb) b rust_panic
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 1612 launched: '/home/builder/delme/target/debug/delme' (aarch64)

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Process 1612 exited with status = 101 (0x00000065)

$ rust-gdb target/debug/delme
...
(gdb) b rust_panic
Function "rust_panic" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (rust_panic) pending.
(gdb) r
Starting program: /home/builder/delme/target/debug/delme
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/nix/store/gydncjm02ww60x9gamkhfwj3f34g3g8m-glibc-2.40-66/lib/libthread_db.so.1".

thread 'main' panicked at src/main.rs:2:5:
panic called
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Inferior 1 (process 1670) exited with code 0145]

$ cat src/main.rs
fn main() {
    panic!("panic called");
}
17:26:56
@dramforever:matrix.orgdramforever i'm not sure if rust_panic is even a real thing, try rust_begin_panic? 17:27:53
@dramforever:matrix.orgdramforeverhuh17:28:42
@dramforever:matrix.orgdramforeverapparently it is supposed to be a thing17:28:48
@cpick:matrix.orgcpickNo joy (same result: neither lldb nor gdb can find the symbol).17:29:12
@dramforever:matrix.orgdramforeverummmmmm17:29:16
@dramforever:matrix.orgdramforeverhow did you build your thing? can you reproduce this with just a clean cargo bin crate?17:30:06
@dramforever:matrix.orgdramforever i just tried gdb and b rust_panic works 17:30:26
@dramforever:matrix.orgdramforevermakes me wonder if you've set some cargo config options to strip or otherwise mess with the symbol table17:30:54
@dramforever:matrix.orgdramforeveri'm on aarch64-linux17:31:10
@cpick:matrix.orgcpick OK, that's encouraging, thanks.
I just created a new NixOS VM, ran nix shell nixpkgs#{cargo,lldb,gcc,rustc,gdb} ran cargo init and replaced println in main.rs with panic, then did cargo build. 		17:32:03
@cpick:matrix.orgcpickSo I shouldn't have any non-stock configuration?17:32:23
@dramforever:matrix.orgdramforeverthat sounds about right17:32:45
@dramforever:matrix.orgdramforever then gdb target/debug/whatever-the-name-is 17:33:08
@cpick:matrix.orgcpick I used rust-gdb, I'll try gdb itself... 17:33:23
@cpick:matrix.orgcpickYeah, same result.17:33:58
@dramforever:matrix.orgdramforeverthat's so weird17:38:28
@dramforever:matrix.orgdramforeverhow recent is this nixpkgs of yours17:38:38
@jose:storopoli.comJose Storopoli joined the room.17:52:23
@cpick:matrix.orgcpick

Good question...
I think this is it?

$ readlink -f /nix/var/nix/profiles/per-user/root/channels
/nix/store/in3n7rsk9rkhdfzsba2kfl1hzv13xbn3-nixos-25.11.20250708.9b008d6
17:54:06
@9hp71n:matrix.orgghpzin (moved to @ghpzin:envs.net) Are you on nixos-25.05 or unstable version before 2025-06-19 ?
I assume it does not work on rustc 1.87+ because of https://github.com/rust-lang/rust/issues/140821 		17:57:23
@9hp71n:matrix.orgghpzin (moved to @ghpzin:envs.net) Are you on nixos-25.05 or unstable version before 2025-06-19 ?
I assume it does not work on rustc 1.87+ because of https://github.com/rust-lang/rust/issues/140821
rustc 1.86 (from nixos-25.05)
(gdb) b rust_panic
Breakpoint 1 at 0x30ff4
rustc 1.87 (from nixos-unstable):
(gdb) b rust_panic
Function "rust_panic" not defined.
18:02:23
@cpick:matrix.orgcpick

Aha! As suggested
rbreak rust_panic worked for me in gdb (no joy with the suggested b s -r rust_panic in lldb, though).

Still that works well for my purposes. Thank you!

18:02:36
@dramforever:matrix.orgdramforeverah, that must be it, i'm on a newer rustc but i forgot that the thing i was debugging was an older one18:10:18
@dramforever:matrix.orgdramforever* ah, that must be it, i'm on a newer rustc but i forgot that the thing i was debugging was compiled with an older one18:10:28

Show newer messages

Back to Room ListRoom Version: 6