GyulyVGC
Sniffnet 1.3.2 crashes with error: `user-provided comparison function does not correctly implement a total order`
Is there an existing issue for this?
- [X] I have searched the existing issues.
What's the problem?
Sniffnet 1.3.2 crashes after selecting the network adapter and starting the analysis, the application crashes. i get following stack trace;
thread 'main' panicked at core/src/slice/sort/shared/smallsort.rs:865:5:
user-provided comparison function does not correctly implement a total order
stack backtrace:
0: 0x5f7b55bb4af9 -
after downgrading to Sniffnet 1.3.1, everything works as it should.
How did you install the app?
downloaded one of the provided packages
Operating System
Linux
Additional context
System:
Kernel: 6.12.8-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/boot/vmlinuz-6.12-x86_64
root=UUID=e0d878c7-******* rw
lsm=landlock,lockdown,yama,apparmor,bpf quiet rd.udev.log_level=3
i915.fastboot=1 audit=0 ipv6.disable=1 i8042.nomux=1 nowatchdog
Desktop: KDE Plasma v: 6.2.5 tk: Qt v: N/A info: frameworks v: 6.9.0
wm: kwin_x11 tools: avail: xtrlock vt: 2 dm: SDDM Distro: Manjaro
base: Arch Linux
Machine:
Type: Portable System: Dell product: Inspiron 5520 v: A14
serial:
It seems something related to Rust 1.81 new sorting implementations.
Unfortunately I'm not able to reproduce this on any of my machines, but I'll try to find a fix.
It seems something related to Rust 1.81 new sorting implementations.
Unfortunately I'm not able to reproduce this on any of my machines, but I'll try to find a fix.
no issues, i've reverted to 1.3.1, and it is functioning fine. let me know if i can help with more debugging from my end.
Thanks!
Yes, I'll need your help to test once I come up with a potential fix.
Thanks very much 👍
Same thing experienced on my system, FWIW.
Because of issue #635 I launched sniffnet as:
ICED_BACKEND=tiny-skia sniffnet
and then it failed with
thread 'main' panicked at core/src/slice/sort/shared/smallsort.rs:865:5:
user-provided comparison function does not correctly implement a total order
as per above.
My OS is Pop!_OS 22.04.
v1.3.1 doesn't experience the error.
Hey guys when does this error happen? In which screen of the application?
I'm asking this to understand where is the comparison function to fix.
As soon as it launches and tries to create a GUI window. I don't remember seeing much of what that window was supposed to be, but judging from the behavior of 1.3.1 when it launches, it's either an initial "no traffic has been detect yet" message or else the Overview window for the main/default adapter.
Oh ok, if it's happening before you see anything, then it is the page where you have to select network adapters an filters.
This is even more strange now as @koshikas is having this issue in the overview page instead.
As mentioned above it could well be the overview page since that seems to be the first page it launches into. It doesn't explicitly ask me to choose an adapter first. The "no traffic yet" message displays for a split second then it goes straight to overview.
Oh ok sorry there was a misunderstanding. I thought it was happening as soon as you started the app.
Ok so the problem is in the overview page for you as well. I'm guessing it's because of the way hosts are being sorted. I'll check again for possible fixes, and I hope to find an OS where I'm able to replicate the issue.
I've built a new binary for you guys to test, find the links here (at the bottom of the page).
This is using the latest dependencies and Rust version. I didn't change sort strategy since it already seems correct to me, I hope this was a problem solved with the newest Rust release.
For reference this is the piece of code used to sort items:
pub fn compare(&self, other: &Self, sort_type: SortType, chart_type: ChartType) -> Ordering {
match chart_type {
ChartType::Packets => match sort_type {
SortType::Ascending => self.tot_packets().cmp(&other.tot_packets()),
SortType::Descending => other.tot_packets().cmp(&self.tot_packets()),
SortType::Neutral => other.final_timestamp.cmp(&self.final_timestamp),
},
ChartType::Bytes => match sort_type {
SortType::Ascending => self.tot_bytes().cmp(&other.tot_bytes()),
SortType::Descending => other.tot_bytes().cmp(&self.tot_bytes()),
SortType::Neutral => other.final_timestamp.cmp(&self.final_timestamp),
},
}
}
As you can see I'm using cmp which implements total ordering, so I can't seem to find the root of the issue.
I've built a new binary for you guys to test, find the links here (at the bottom of the page).
just tried small issue on archlinux we are running libpcap 1.10.5. and the build you provided seems to be looking for libpcap 0.8.x. is there any way get libpcap further upstream to build at your end
error i get with your build; ./sniffnet: error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory
Unfortunately the package I build aren't for Arch Linux. However you can try checking the required dependencies, but not sure it'll work on Arch since there you have to install via pacman.
Unfortunately the package I build aren't for Arch Linux. However you can try checking the required dependencies, but not sure it'll work on Arch since there you have to install via pacman.
not a issue let me try compile libpcap myself, can yo confirm me the exect version of libpcap required here
libpcap0.8
sorry i'm running into issues building that old of libcap build, all its dependecies have moved on since (sh of all things)
Same issue for me, with that build.
It is definitely on the overview page, after getting past the "No traffic has been observed yet" message.
edit: Not a Rust-knower myself, but perhaps the match statements need default match-everything-else patterns to satisfy the analysis?
In this case it's not needed since I'm just matching against all the variants of an enum. So there are no other cases possible.
Today I've found out that this might be due to https://github.com/iced-rs/iced/issues/2650, which was already fixed in https://github.com/iced-rs/iced/pull/2651.
As soon as Iced gets updated I will provide you guys a new binary so that we can verify if the problem is solved.
I can reproduce this:
thread 'main' panicked at library/core/src/slice/sort/shared/smallsort.rs:860:5: user-provided comparison function does not correctly implement a total order note: run with
RUST_BACKTRACE=1environment variable to display a backtrace
I'm seeing similar with the latest docker container on Ubuntu 22.04 host and starting with the example Wayland instructions.
$ docker run -it --net=host -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY -e XDG_RUNTIME_DIR=/tmp -e RUST_BACKTRACE=full -e ICED_BACKEND=tiny-skia --cap-add=NET_ADMIN --cap-add=NET_RAW ghcr.io/gyulyvgc/sniffnet:latest
╭────────────────────────────────────────────────────────────────────╮
│ │
│ Sniffnet 1.4.0 │
│ │
│ → Website: https://sniffnet.net │
│ → GitHub: https://github.com/GyulyVGC/sniffnet │
│ │
╰────────────────────────────────────────────────────────────────────╯
thread 'main' panicked at library/core/src/slice/sort/shared/smallsort.rs:860:5:
user-provided comparison function does not correctly implement a total order
stack backtrace:
0: 0x5a9e20a9d786 - <unknown>
1: 0x5a9e20250dc3 - <unknown>
2: 0x5a9e20a9d1af - <unknown>
3: 0x5a9e20a9d4c3 - <unknown>
4: 0x5a9e20a9ce8e - <unknown>
5: 0x5a9e20ad8da5 - <unknown>
6: 0x5a9e20ad8d39 - <unknown>
7: 0x5a9e20ad982c - <unknown>
8: 0x5a9e2011f7af - <unknown>
9: 0x5a9e2011ff0a - <unknown>
10: 0x5a9e2039b0e5 - <unknown>
11: 0x5a9e20393393 - <unknown>
12: 0x5a9e20392def - <unknown>
13: 0x5a9e20392def - <unknown>
14: 0x5a9e2039c104 - <unknown>
15: 0x5a9e209a1fbb - <unknown>
16: 0x5a9e2018cb70 - <unknown>
17: 0x5a9e201993dd - <unknown>
18: 0x5a9e209b558d - <unknown>
19: 0x5a9e20a18ff2 - <unknown>
20: 0x5a9e20197f7b - <unknown>
21: 0x5a9e2096a70e - <unknown>
22: 0x5a9e20a038d3 - <unknown>
23: 0x5a9e20967d3d - <unknown>
24: 0x7150823fe24a - <unknown>
25: 0x7150823fe305 - __libc_start_main
26: 0x5a9e2017b3b1 - <unknown>
27: 0x0 - <unknown>
$
Appears to fail after selecting an interface showing the overview page, time to failure varies, have seen it when trying to return from fingernail mode.
installed with pacman -S sniffnet on arch sniffnet GUI opens I click start button ╭────────────────────────────────────────────────────────────────────╮ │ │ │ Sniffnet 1.4.0 │ │ │ │ → Website: https://sniffnet.net │ │ → GitHub: https://github.com/GyulyVGC/sniffnet │ │ │ ╰────────────────────────────────────────────────────────────────────╯
MESA-INTEL: warning: Ivy Bridge Vulkan support is incomplete
thread 'main' panicked at library/core/src/slice/sort/shared/smallsort.rs:860:5:
user-provided comparison function does not correctly implement a total order
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
small update, based on the comment above, i have a feeling this has some thing to do with the graphics stack.
i have 2 laptops both running archlinux. the one having AMD GPU runs sniffnet 11.4.0 with no issues. it is the one with Ivy bridge (intel 3rd gen CPU) with integrated graphics that i get the same error.
Yes, I'm also pretty sure it has to do with the graphics stack, particularly I believe this is related with iced as I mentioned:
Today I've found out that this might be due to iced-rs/iced#2650, which was already fixed in iced-rs/iced#2651.
As soon as Iced gets updated I will provide you guys a new binary so that we can verify if the problem is solved.
I hope for a new version of the library coming soon from them
Hey guys, I'm migrating (#1032) to the new version of Iced that possibly fixed this issue. I need your help to verify that the problem is gone.
Here you can find the packages built on top of #1032.
@neogeographica tagging you since you were the only one that was able to download and test a DEB package from my workflows I think.
@GyulyVGC that does seem to fix things... I can launch and use it without any issues now.
Also it looks like I no longer need to use this: ICED_BACKEND=tiny-skia
Awesome 🤩
This means that Sniffnet v1.5.0 will finally fix this issue!
Thanks for the confirmation.
Hey guys, I'm migrating (#1032) to the new version of Iced that possibly fixed this issue. I need your help to verify that the problem is gone.
Verified issue is resolved with amd64 AppImage for following environment:
Void Linux wayland GNOME DE Intel® UHD Graphics 620 (KBL GT2)
