trimental
Core dump on closing
Hi,
I've just updated the NetBSD package to 0.5.0.
Thanks for the improvements.
I'm facing a weird issue, though. Everything is working fine but, everytime I close the program, I get a core dump.
I use a tiling window manager so, closing the client kills the program but, why is that causing a core dump?
gdb won't tell me anything unless, I build the software with debug symbols enabled. Which, I could do but, haven't done, yet.
Thanks for the issue (and for packaging inlyne)
I'm not too sure on what exactly would be causing a seg fault 🤔. I'm not able to repro on Linux (neither on Arch nor Pop OS). I just opened #389 which you could try using to see if its an issue in one of our dependencies that's been fixed in a more recent version
There is a tiny bit of unsafe used in inlyne itself that could possibly be the source too. It's exclusively used for:
- Clipboard management that takes a pointer to the window's display handle
- Creating a wgpu surface from a window handle
1. would be easy enough to rip out as a test, 2. not so much although both of these usages of unsafe date back to older versions where this wasn't an issue I would assume
The only other likely source of a seg fault in Rust (that I'm aware of) is from overflowing the stack, but Rust sets up guard pages to print out a special message in that case
I've packaged inlyne back in 2023-05-09, version 0.3.0 was the first one available in the packages repository 😉
I've now built locally (both release and #389) with enabled debug symbols but, it doesn't look very helpful 😞
~> uname -rsv
NetBSD 10.99.12 NetBSD 10.99.12 (GENERIC) #0: Wed Jan 22 12:56:21 UTC 2025 [...]
~> rustc -V
rustc 1.84.1 (e71f9a9a9 2025-01-27) (built from a source tarball)
[...] # Fetching the release tarball and unpacking
~> cargo build --no-default-features --features x11
[...]
~> inlyne view README.md
[...] # Use the software, scroll through the text and close the client
Exception: inlyne killed by signal segmentation fault (core dumped)
[tty 12]:1:1-22: inlyne view README.md
~> gdb inlyne inlyne.core
GNU gdb (GDB) 15.1
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from inlyne...
[New process 14483]
[New process 12550]
[New process 16684]
[New process 15726]
[New process 16097]
[New process 15744]
[New process 15680]
Core was generated by `inlyne'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007737e09beba7 in ?? ()
[Current thread is 1 (process 14483)]
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file inlyne.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0 0x00007737e09beba7 in ?? ()
#1 0x00007737e2d806ad in ?? ()
#2 0x00007737e2b69220 in ?? ()
#3 0x0000000000000000 in ?? ()
(gdb) quit
[...] # Fetching and unpacking 03b0d7d3b4194f910b71592256477748d6983466
~> cargo build --no-default-features --features x11
[...]
~> inlyne view README.md
[...] # Use the software, scroll through the text and close the client
Exception: inlyne killed by signal segmentation fault (core dumped)
[tty 31]:1:1-22: inlyne view README.md
~> gdb inlyne inlyne.core
[...]
Reading symbols from inlyne...
[New process 29059]
[New process 5811]
[New process 5797]
[New process 6523]
[New process 1959]
[New process 2091]
[New process 29840]
Core was generated by `inlyne'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000072f4207feba7 in ?? ()
[Current thread is 1 (process 29059)]
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file inlyne.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) bt
#0 0x000072f4207feba7 in ?? ()
#1 0x000072f422c866ad in ?? ()
#2 0x000072f422a6f120 in ?? ()
#3 0x0000000000000000 in ?? ()
(gdb) quit
Unfortunately, I seem to have missed this before as I also did a build of 0.4.3 and it also generates a core dump.
I don't think not seeing it on Linux means too much, I believe most Linux distros disable core dumps by default these days. I've also built 0.5.0 on MacOS aarch64 and there I don't get a core dump either. I'll try to go further back in the releases and will probably rebuild the Rust compiler, just in case.
Yup, I recognized you :). Thanks for all of the extra info. I can work on getting a branch pushed that removes the clipboard code and we can see if that makes a difference
(I am gonna be on vacation all of next week though)
Why do you think this is an issue with clipboard?
I am gonna be on vacation all of next week though
No worries, have a nice holiday
Why do you think this is an issue with clipboard?
It's one of the only direct usages of unsafe which are generally the cause of seg faults in rust, but it's mostly just a blind guess
Re: the gdb output
Is the inlyne you're invoking the one built with debug info or is it a different one in your PATH? Some kind of backtrace would be immensely helpful
Some kind of backtrace would be immensely helpful
Yes, I know. I've tried 😞
Yes, there is only my local build present on the system and yes, it was built with cargo build and not cargo build --release.
Unfortunately, I don't know how to handle the following:
[Current thread is 1 (process 29059)]
warning: Unsupported auto-load script at offset 0 in section .debug_gdb_scripts
of file inlyne.
Use `info auto-load python-scripts [REGEXP]' to list them.
@CosmicHorrorDev I've asked a fellow NetBSD dev to test. He has built it from git-HEAD using Rust-1.82 and does not get any core dump. Please wait until I've rebuilt the rust compiler and tested before you introduce any changes.
What do you say @CosmicHorrorDev ?
Since, this is not happening to my fellow dev should we just close this issue? I can't seem to get a proper backtrace anyway 😞
The software is working as intended after all.
I think we can keep this open and see if anyone else hits the same issue and is able to provide more insight