!FBuJyWXTGcGtHTPphC:nixos.org

Nix Rust

590 Members
Rust132 Servers

Load older messages


SenderMessageTime
9 Jul 2025
@salacious-silverback:matrix.orgsohrobinator set a profile picture.04:04:35
@atagen:ch.atagen.coatagen joined the room.07:40:33
10 Jul 2025
@setthemfree:matrix.orgundltd At least for a package that contains both the code and default.nix (and flake.nix, but that shouldn't be relevant), setting cargoDepsName = pname; doesn't seem to have the effect of decoupling cargoHash from the package version, at least when the version in default.nix and Cargo.toml are the same. I.e., if I change the package version in Cargo.toml, cargo also updates the version in Cargo.lock, and cargoHash changes. I'm a bit confused by the documentation though:

>> The tarball with vendored dependencies contains a directory with the package’s name, which is normally composed of pname and version. This means that the vendored dependencies hash (cargoHash) is dependent on the package name and version. The cargoDepsName attribute can be used to use another name for the directory of vendored dependencies. For example, the hash can be made invariant to the version by setting cargoDepsName to pname: <...>

This sounds as though cargoHash wound then not depend on the package version anymore, but this is not what I see in practice.

Additionally, adding or removing cargoDepsName = pname; does not change cargoHash - but I expected it to change based on the quoted paragraph from the docs (i.e., the directory name inside the tarball should have changed). What does cargoDepsName really do?
20:09:45
@setthemfree:matrix.orgundltdThe package in question: https://codeberg.org/undltd/om/src/branch/main/default.nix20:11:23
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 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

Show newer messages


Back to Room ListRoom Version: 6