Re: Certain numbers of special forms cause changing behaviour on function calls in --batch

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 10 Jul 2016 13:03:17 -0400
> Cc: Yasushi SHOJI <yasushi.shoji@gmail.com>, Michael Heerdegen <michael_heerdegen@web.de>, me@wilfred.me.uk, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, Jul 10, 2016 at 12:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> I don't think Fzerop is especially relevant, AFAICT, the error just
> >> means Fzerop received an unitialized value as its first argument.
> >
> > Sorry, I;m not following: Fzerop is called from Ffuncall, i.e. from
> > Lisp, so how can the value of Fzerop's argument be uninitialized?
> > What am I missing?
> 
> Possibly there is an error in the bytecode interpreter?

Could be, but IMO unlikely: such a problem would appear all over the
place, not just in some obscure script.

> Is there an easy way to trace pushes and pops to the stack?

Maybe, but since we already know this is a Heisenbug, I very much
doubt we will be able to catch it that way.  We don't even know if the
call to zerop is related to the problem.

I still think we should try continuing what Michael started, but each
time you make a change in simple.el, re-dump Emacs before trying the
recipe.  (And make very small changes each time, because it looks like
large changes make the bug disappear.)  The idea is to see why does
Emacs move an extra line in batch mode, and I think the answer is
somewhere inside move-end-of-line or functions/subroutines it calls.