GNU bug report logs - #77389
31.0.50; Restarting Emacs with (kill-emacs ... t) looses noninteractivity

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
Cc: 77389 <at> debbugs.gnu.org
Subject: bug#77389: 31.0.50; Restarting Emacs with (kill-emacs ... t) looses noninteractivity
Date: Thu, 03 Apr 2025 08:10:48 +0300

> Date: Wed, 2 Apr 2025 22:54:23 +0200
> Cc: 77389 <at> debbugs.gnu.org
> From: Jens Schmidt <jschmidt4gnu <at> vodafonemail.de>
> 
> > Why do you need to write Lisp to a file, only to have that file read
> > and executed? why not simply execute that Lisp directly in the
> > original session?
> 
> Because the state of the original session (most notably the loaded
> features) influences (and gets influenced by) that Lisp.

I know the theory, but why is it a problem in practice?  We bump into
this issue every day, because doing stuff from an Emacs session that
runs for some time will always produce results that depend on what
happened in that session beforehand.

If you really do need to do something in a pristine Emacs, do that in
a separate sub-process, then read the results.  That's what we do with
native-compilation, for example.

> >> The only thing that bothers me a bit is that there is the following
> >> memory-related initialization being executed in main *after*
> >> copy_raw_args (or also the present sort_args) have already been
> >> allocating memory:
> > 
> > Why does this bother you?  The old session is going down, and the new
> > one will re-execute that part anew, no?  What did I miss?
> 
> I'm not talking about old or new session here.  What bothers me is
> also independent of this bug, I just came across it while staring at
> the surrounding code.  Namely at the comment in this block:
> 
>   /* Call malloc at least once, to run malloc_initialize_hook.
>      Also call realloc and free for consistency.  */
>   free (realloc (malloc (4), 4));
> 
> This sounds like this is initialization that better should be
> executed *before* any actual call to malloc is done.  Which is
> currently not the case, since, for example, sort_args can call
> (x)malloc and sort_args is called before the block quoted above.
> But then I do not really understand what that block is about and
> my concerns may be completely unsubstantiated.

Yes, we call heap allocation functions before that, so you don't need
to worry about that.  The purpose of that line is not to initialize
malloc, it's something else.

> But back to my patch: I did a cursory grep for initial_arg[cv]
> through current master.  From the results I got the impression
> that instead of setting up a second copy raw_initial_arg[cv]
> like done in the first patch, one could also try to directly
> use initial_arg[cv], like in the attached alternative patch.
> Should I go that route instead or would that be too risky,
> anyway?

That's a possibility, but please make all this copy_raw_args and its
calls #ifdef'ed away on WINDOWSNT, since we already do something like
that there, just better.  Also, these additions need comments to
explain why we do this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.