I feel like the intent of your a_crash semantics are "no, really, crash no matter what", and using possibly-catchable signals don't quite match that.
-
-
-
Right now it *is* catchable, just because we didn't have a good way to make it non-catchable. Now the tail of abort() provides a way to do so, if we want to.
-
I know, it just always felt like an accident that really violated intent.
-
Yeah I'd even considered SIGKILL before, but it's unfriendly to debugging.
End of conversation
New conversation -
-
-
Other: work with kernel to introduce an interface to terminate the process "here and now". I think
@sortiecat has the right idea with scram(2). (and I raise eyebrows at the "uncatchable", nothing is stopping the program from installing a handler via raw syscalls) -
Installing via raw syscalls alone doesn't do it. You still have to successfully race against the thread that's trying to terminate. See https://git.musl-libc.org/cgit/musl/commit?id=9b14ad541068d4f7d0be9bcd1ff4c70090d868d3 …
-
It would be nice to have a syscall to do it all faily-safe and atomically, but in the absence of one I was pretty happy to find a solution that works this well for abort, and it still seems better than the status quo for where a_crash() is currently used.
-
Sortix currently implements abort() with exit_thread() (backend of _exit) that can atomically unconditionally exit and fake the exit code as if by a signal. I have considered doing it with scram(2). Question is how much alerting I want to go off on abort().
-
Neither exit_thread (undocumented) / scram(2) are necessarily long term interfaces, they were designed to reasonably solve the problem of the day and do it right. We shouldn't be afraid of adding new system calls to Linux if there's no reliable & simple way to do stuff in libc.
-
(Yes -- Linux ABI is long term, but there it's worth to discuss stuff through and come up with a long term good design from the start, and keep total kernel + userland complexity in mind)
End of conversation
New conversation -
-
-
Why would you ever want bad state to be catchable?
-
Because you don't understand that introspective crash reporting/debugging simply gives attackers a vector to turn a DoS into an RCE, and are trying to auto-report crashes or get users to report them without running gdb...
End of conversation
New conversation -
-
-
My answer may have been different if you didn't include "[n unintentionally]"
-
Hope it made sense. The sense I intended was that a_crash() being catchable in the past was not an intended property, just a consequence of it being hard to prevent.
-
Yep. The parenthetical comment resulted in a more considered choice.
End of conversation
New conversation -
-
-
No, please keep it. In a system, we'd like SIGABRT when errors are being detected (internally), and masking e.g. SIGSEGV with it would cause a lot of time wasted investigating red herrings.
-
I don't understand the "no, please keep it" aspect. Current behavior is crashing with a SIGSEGV or SIGILL (arch dependent) that could be caught just like any other one. Proposal is generating an uncatchable SIGABRT instead.
-
I meant option #2
End of conversation
New conversation -
-
-
Both Abort and segv is sometimes cought by crashhandlers for statistics and helpful feedback to the user. Should be catchable. Corrupt libc state should not be catchable.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.