From: Noam Postavsky <npostavs@users.sourceforge.net>
To: Yasushi SHOJI <yasushi.shoji@gmail.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
Eli Zaretskii <eliz@gnu.org>,
me@wilfred.me.uk, Emacs developers <emacs-devel@gnu.org>
Subject: Re: Certain numbers of special forms cause changing behaviour on function calls in --batch
Date: Sun, 10 Jul 2016 07:33:47 -0400 [thread overview]
Message-ID: <CAM-tV-8m_mdSNecTqPORzHkULJ+59YPJ=RsaX6rV8R+DMEfv9w@mail.gmail.com> (raw)
In-Reply-To: <CAELBRWJroRrC1d=m9TbVtWzLq4B2zO611MqC+SZOH9SAMS+F4w@mail.gmail.com>
On Sun, Jul 10, 2016 at 7:13 AM, Yasushi SHOJI <yasushi.shoji@gmail.com> wrote:
> On Sun, Jul 10, 2016 at 7:34 PM, Yasushi SHOJI <yasushi.shoji@gmail.com>
> wrote:
>> On Thu, Jul 7, 2016 at 12:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > So more data points might help, yes.
>>
>> I can reproduce this bug on my Debian Sid system with
>> gcc version 5.4.0 20160609 (Debian 5.4.0-6).
>
> I should have tested with different compilers before posting the
> previous comment since Eli predicted that a bad compiler is a problem.
>
> Yes, the results differ depending on the compiler you use.
I have gcc 5.3.0 here, and I get 10 (correct) when I compile Emacs
24.5 configured with --enable-checking, but 20 (incorrect) without
that flag. In both cases running temacs with valgrind gives some
errors which look suspicious (the version without --enable-checking
additionally gives a bunch of what I assume are false positives while
starting up). Emacs 25 gives similar errors (I haven't tried Emacs 25
without --enable-check).
(I'm showing here just the results from the --enable-checking
versions, without it's the same except for printing 20 instead of 10)
valgrind emacs-24.5/src/temacs -Q --batch -l nasty-move-end-of-line-batch.el
[...]
==6167== Conditional jump or move depends on uninitialised value(s)
==6167== at 0x55E74E: CHECK_NUMBER_OR_FLOAT (lisp.h:2627)
==6167== by 0x5EC762: Fzerop (data.c:2387)
==6167== by 0x608571: Ffuncall (eval.c:2811)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608A99: apply_lambda (eval.c:2919)
==6167==
==6167== Conditional jump or move depends on uninitialised value(s)
==6167== at 0x5EC76B: Fzerop (data.c:2389)
==6167== by 0x608571: Ffuncall (eval.c:2811)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608A99: apply_lambda (eval.c:2919)
==6167== by 0x6070E9: eval_sub (eval.c:2226)
==6167==
==6167== Conditional jump or move depends on uninitialised value(s)
==6167== at 0x5EC7B4: Fzerop (data.c:2396)
==6167== by 0x608571: Ffuncall (eval.c:2811)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608764: Ffuncall (eval.c:2860)
==6167== by 0x650F35: exec_byte_code (bytecode.c:916)
==6167== by 0x608DA1: funcall_lambda (eval.c:2978)
==6167== by 0x608A99: apply_lambda (eval.c:2919)
==6167== by 0x6070E9: eval_sub (eval.c:2226)
==6167==
point is: 10
==6167==
==6167== HEAP SUMMARY:
[...]
valgrind emacs-25/src/temacs -Q --batch -l nasty-move-end-of-line-batch.el
[...]
==6186== Conditional jump or move depends on uninitialised value(s)
==6186== at 0x67110E: exec_byte_code (bytecode.c:1367)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624EA5: apply_lambda (eval.c:2794)
==6186== by 0x6234AA: eval_sub (eval.c:2211)
==6186== by 0x61E3C6: Fprogn (eval.c:426)
==6186== by 0x622F55: eval_sub (eval.c:2119)
==6186==
==6186== Conditional jump or move depends on uninitialised value(s)
==6186== at 0x6711D8: exec_byte_code (bytecode.c:1370)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624EA5: apply_lambda (eval.c:2794)
==6186== by 0x6234AA: eval_sub (eval.c:2211)
==6186== by 0x61E3C6: Fprogn (eval.c:426)
==6186== by 0x622F55: eval_sub (eval.c:2119)
==6186==
==6186== Conditional jump or move depends on uninitialised value(s)
==6186== at 0x6712C1: exec_byte_code (bytecode.c:1379)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624B3A: Ffuncall (eval.c:2742)
==6186== by 0x66F310: exec_byte_code (bytecode.c:880)
==6186== by 0x625203: funcall_lambda (eval.c:2855)
==6186== by 0x624EA5: apply_lambda (eval.c:2794)
==6186== by 0x6234AA: eval_sub (eval.c:2211)
==6186== by 0x61E3C6: Fprogn (eval.c:426)
==6186== by 0x622F55: eval_sub (eval.c:2119)
==6186==
point is: 10
==6186==
==6186== HEAP SUMMARY:
[...]
next prev parent reply other threads:[~2016-07-10 11:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-26 16:39 Certain numbers of special forms cause changing behaviour on function calls in --batch Wilfred Hughes
2016-06-28 21:12 ` Michael Heerdegen
2016-06-29 16:23 ` Eli Zaretskii
2016-06-29 20:39 ` Michael Heerdegen
2016-06-30 2:38 ` Eli Zaretskii
2016-06-30 12:34 ` Michael Heerdegen
2016-06-30 15:19 ` Eli Zaretskii
2016-06-30 21:10 ` Michael Heerdegen
2016-07-01 7:21 ` Eli Zaretskii
2016-07-05 21:21 ` Michael Heerdegen
2016-07-05 21:33 ` Michael Heerdegen
2016-07-06 14:30 ` Eli Zaretskii
2016-07-06 14:47 ` Michael Heerdegen
2016-07-06 15:04 ` Eli Zaretskii
2016-07-10 10:34 ` Yasushi SHOJI
2016-07-10 11:13 ` Yasushi SHOJI
2016-07-10 11:33 ` Noam Postavsky [this message]
2016-07-10 14:53 ` Eli Zaretskii
2016-07-10 16:23 ` Noam Postavsky
2016-07-10 16:45 ` Eli Zaretskii
2016-07-10 17:03 ` Noam Postavsky
2016-07-10 17:29 ` Eli Zaretskii
2016-07-10 17:10 ` Andreas Schwab
2016-07-10 17:37 ` Eli Zaretskii
2016-07-10 18:40 ` Paul Eggert
2016-07-10 19:09 ` Eli Zaretskii
2016-07-10 17:37 ` Andreas Schwab
2016-07-10 18:02 ` Eli Zaretskii
[not found] ` <<83inwde5gv.fsf@gnu.org>
2016-07-10 18:20 ` Drew Adams
2016-07-10 21:44 ` Clément Pit--Claudel
2016-07-06 14:28 ` Eli Zaretskii
2016-06-30 5:58 ` Andreas Röhler
2016-06-30 15:13 ` Eli Zaretskii
2016-06-30 17:20 ` Andreas Röhler
2016-06-30 17:40 ` Eli Zaretskii
2016-06-30 21:22 ` Michael Heerdegen
2016-07-01 7:13 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM-tV-8m_mdSNecTqPORzHkULJ+59YPJ=RsaX6rV8R+DMEfv9w@mail.gmail.com' \
--to=npostavs@users.sourceforge.net \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=me@wilfred.me.uk \
--cc=michael_heerdegen@web.de \
--cc=yasushi.shoji@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).