When I used Debian exclusively, I used stable only. It was during that time that I added "can't even do updates right" to my list of gripes against Debian. What I use now is irrelevant, because I don't use the system I have it installed on heavily. In fact, about all I ever do with it these days is charge the battery to hopefully keep it from dying and update what few things I have installed on there.

it still can't do proper updates and even has the nerve to omit certain packages from repos. after my update from stretch to buster I had to roll back older kernel, switch Nautilus to PCManFM, remove Budgie in favor of openbox/compton/tint2 (was completely broken mess with older kernel) and manually add from elsewhere phpmyadmin and php7.0. Ah and my playonlinux for some reason can't create its windows but that's not the most grief. Basically I had to roll back kernel and remove all bits of gnome they flushed in. That's not what I would call a successful distro upgrade
I'll use it for a while and will switch to Arch. Debian had its benefits but I don't want to reinstall every 1-2 years.

Huh, looks like I'm not the only one who's had a bitter experience with Debian. I gave it a chance, not once but twice and each time it made me want to throw a computer out the window..

Needless to say, my family members' misadventures with Debian derivatives don't give it any additional positive light.

I had no big issues with it for years, it just this last distro upgrade went south for them. Debian maintainers should keep more attention to what they push.

If I open htop, then use it to send itself SIGSEGV, htop will crash with a message saying to report this bug.

Should I report it?

(This also happens with top.)

Also, to crash the Python interpreter, the following will work:
>>> import os
>>> os.kill(os.getpid(), 11)
Segmentation fault

(Exercise for the reader: Why does the Python code crash the interpreter, and how would you fix it so that it works correctly?)

What's incorrect about it? I'm not even sure there's a legit use case for handling sigsegv today, I think these programs should just be unconditionally killed.

Well, the program *does* crash when it's executed, right?

Debuggers and debugging tools often need to handle SIGSEGV in order to allow such errors to be debugged. (valgrind is an example here; if a SIGSEGV occurs, it prints a backtrace and a summary of memory usage.)

Also, IIRC user mode linux uses SIGSEGV internally. Interestingly enough, an OS kernel actually handles the kernel-mode equivalent in an interesting way; the kernel checks to see if the memory reference was valid, and if it was, loads the memory contents from disk (either from the file backing the memory region, or from the swap partition/file), then lets the process that continued it continue as if nothing happend.

Right, but if it handles SIGSEGV, it could avoid crashing. I don't think that's something unprivileged code should be able to do, ever, as a program that's intended to be native and portable and run on a system with virtual memory. Maybe there's some excuse for emulators and such that need to support broken non-native code, but even then I think there should be proper architecture in place instead of spaghetting' things together with SIGSEGV handlers, unportable mmap extensions/assumptions, etcetra. IMHO that's just a hack to work around the lack of better architecture, as expected from a system designed in the 70s. About as hacky as what ldd did (and on many systems sill does), which is to just set an environment variable and then execute the program whose library dependencies you wanted to inspect, with the expectation that the run-time link editor does the right thing. Ugh.

What you can do safely or correctly in a signal handler is not much, so real debuggers are going to need something more advanced like ptrace anyway. I think that's kinda the way things should've always been; the system should provide an out-of-band (and higher privilege) mechanism for debuggers to interact/interfere with the debuggee. Delivering signals to the debuggee in order to enable some sort of limited debugging is very very backwards. If there's some asynchronous event that the debugger should be able to be notified of and which cannot be monitored e.g. by hooking into system calls, then provide a mechanism for the debugger only to subscribe to such events. Sure, handling page faults and other hardware exceptions in kernel (or other more privileged, if we want to consider microkernel architecture) code is fair game. I'm not sure how I feel about instruction emulation; I haven't thought much about it to say whether it's reasonable to handle unimplemented instructions in userspace software without kernel intervention (and the associated performance penalty).

If you want a signal that can't be caught by an unprivileged code (or any code not running as PID 1, for that matter), there's SIGKIIL. (Also, SIGSTOP, which could be useful if a program is causing the machine to overheat, for example, but that doesn't eliminate the process in question.)