GNU bug report logs - #23369
25.0.93; CANNOT_DUMP build fails if resizing terminal during startup in tty mode

Previous Next

Full log

Message #34 received at 23369 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 23369 <at> debbugs.gnu.org, fredrik <at> fornwall.net
Subject: Re: bug#23369: 25.0.93;
 CANNOT_DUMP build fails if resizing terminal during startup in tty
 mode
Date: Wed, 27 Apr 2016 22:27:05 +0300

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: fredrik <at> fornwall.net,  23369 <at> debbugs.gnu.org
> Date: Wed, 27 Apr 2016 14:48:41 -0400
> 
> Eli Zaretskii wrote:
> 
> > I'd still like to see a full backtrace when the problem happens, both
> > C and Lisp level.
> 
> I can't get one. I just get "NSTATICS too small" (even if I make it huge).

If you run that command under GDB, with a breakpoint on the code which
issues this message, don't you get the backtrace?

> >> Also, it seems like if CANNOT_DUMP builds encounter an error loading
> >> loadup.el, they go on to run the command-loop with only a partially
> >> loaded loadup, which leads to confusing error messages that have nothing
> >> to do with the real problem. Can they be made to abort instead?
> >
> > How will aborting help diagnosing the problems?  IME, it tends to hide
> > evidence, not make it more clear.
> 
> In that Emacs might stop near the actual error (eg "loading foo..."),
> rather than going on to fail with some totally unrelated error (eg
> "Symbol's function definition is void: internal-echo-keystrokes-prefix"
> as in this case).

But the error message is actually quite informative; at the very
least, it tells where the problem happened, and frequently also names
the guilty function or variable.

Previous Next

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