Re: SBCL 2.3.11: Core dump after typing Control-4

On 2025-06-22 at 19:28:29 -0400,
[email protected] wrote:

> Michał "phoe" Herda <[email protected]> writes:
> 
> > On 23.06.2025 00:43, [email protected] wrote:
> >> Is there an argument for continuing the current behavior,
> >> that is, is it useful for SBCL to allow a user to interrupt
> >> the lisp and dump core under some circumstances?
> >
> > The behaviour you are describing is the default for all Unix processes 
> > running in terminals. It's not the duty of SBCL to document OS defaults.
> >
> 
> It is the behavior, but it does not have to be.  Is it
> useful behavior or does it serve no purpose?

SIGQUIT serves exactly the purpose you discovered:  to cause a running
program to dump its core.  Maybe you personally don't have a use for
core files in general, or SBCL's core files in specific, but that
doesn't mean that the behavior is not useful, or that some user won't
get surprised (in the bad way) if SBCL changes its behavior now.

In the general case, a core file can be the last resort to debug
compiler problems or other issues that baffle even a good debugger.

> > Speaking in another way: is the behaviour you describe documented 
> > anywhere for Python, Ruby, Perl, Erlang, and so on? I'm asking because 
> > the Unix python/irb/perl/erl programs react in the very same way - 
> > quitting and optionally producing core dumps.
> >
> 
> I do not know about how those programs behave, but it is
> beside the point of my question.

POSIX systems are general purpose, and designed to serve multiple uses
and multiple users (often simultaneously, on both fronts).  Running SBCL
is one such use, and I imagine that the number of POSIX users who use
their system exclusively to run SBCL is relatively small.

I'm not arguing against documenting SBCL's behavior in the face of a
SIGQUIT, if only to note that SBCL doesn't do anything special (although
the argument against documenting standard OS or glibc behavior is pretty
strong).

> > Or in yet another way: where does the man page for the Unix cat binary 
> > mention this? Because hitting Ctrl+4 on a running cat process does the same.
> >
> 
> That ‘cat’ does is not significant as it is not a program
> that users expect to interact with for long period without
> dying unexpectedly.  Also, ‘cat’ might well want to
> recognize a quit signal.  Does it serve a lisp to recognize
> the quit signal and if so what purpose does it serve?  And
> if not, can it be changed so that it intercepts and ignores
> a quit signal (as many other programs do)?

Again, your expectations of cat may or may not be typical.  I've been at
this for decades, and I still get surprised by other user's workflows.

It could well serve a lisp to recognize SIGQUIT and execute
save-lisp-and-die (or equivalent) with a particular set of arguments.
(I am not proosing such a thing, but I know better than to preclude
someone else from creating a workflow that I hadn't thought about.)


_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help