From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Certain numbers of special forms cause changing behaviour on function calls in --batch Date: Sun, 10 Jul 2016 20:29:58 +0300 Message-ID: <83oa65e6zt.fsf@gnu.org> References: <8760stvwzp.fsf@web.de> <834m8cvu9p.fsf@gnu.org> <87h9cbpw61.fsf@web.de> <83wpl7v1sg.fsf@gnu.org> <87a8i2dfe3.fsf@web.de> <83poqyvh58.fsf@gnu.org> <87shvu1ixp.fsf@web.de> <8360spvn6i.fsf@gnu.org> <8760sjn5me.fsf@web.de> <871t37n51y.fsf@web.de> <8337nmon4l.fsf@gnu.org> <87mvluomaz.fsf@web.de> <83mvlun6zc.fsf@gnu.org> <83bn25fst6.fsf@gnu.org> <83vb0de91c.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1468171826 16477 80.91.229.3 (10 Jul 2016 17:30:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jul 2016 17:30:26 +0000 (UTC) Cc: michael_heerdegen@web.de, yasushi.shoji@gmail.com, me@wilfred.me.uk, emacs-devel@gnu.org To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 10 19:30:20 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bMIYc-0004wJ-AZ for ged-emacs-devel@m.gmane.org; Sun, 10 Jul 2016 19:30:18 +0200 Original-Received: from localhost ([::1]:56136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMIYb-0006D1-IM for ged-emacs-devel@m.gmane.org; Sun, 10 Jul 2016 13:30:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43445) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMIYV-0006BC-ST for emacs-devel@gnu.org; Sun, 10 Jul 2016 13:30:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bMIYR-0001qh-Lo for emacs-devel@gnu.org; Sun, 10 Jul 2016 13:30:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bMIYR-0001oR-IK; Sun, 10 Jul 2016 13:30:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3132 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bMIYP-0001GU-1y; Sun, 10 Jul 2016 13:30:05 -0400 In-reply-to: (message from Noam Postavsky on Sun, 10 Jul 2016 13:03:17 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:205514 Archived-At: > From: Noam Postavsky > Date: Sun, 10 Jul 2016 13:03:17 -0400 > Cc: Yasushi SHOJI , Michael Heerdegen , me@wilfred.me.uk, > Emacs developers > > On Sun, Jul 10, 2016 at 12:45 PM, Eli Zaretskii 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.