From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#30626: 26.0.91; Crash when traversing a `stream-of-directory-files' Date: Thu, 01 Mar 2018 12:25:43 +0100 Message-ID: <87muzs11hk.fsf@web.de> References: <87inaiss6l.fsf@web.de> <6FCF6ACA-4F29-4B6B-BE9D-D7130C6E9495@gnu.org> <87fu5moe4c.fsf@web.de> <877eqyocro.fsf@web.de> <83zi3uz4nb.fsf@gnu.org> <87lgfd52by.fsf@gmail.com> <87bmg91ity.fsf@web.de> <83h8q1yuin.fsf@gnu.org> <87po4pnl0a.fsf@web.de> <837eqxyqoe.fsf@gnu.org> <87lgfdnf86.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1519904608 29047 195.159.176.226 (1 Mar 2018 11:43:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Mar 2018 11:43:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) Cc: npostavs@gmail.com, 30626@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 01 12:43:23 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erMcN-0006vn-AP for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Mar 2018 12:43:23 +0100 Original-Received: from localhost ([::1]:55814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erMdP-0004Ev-MP for geb-bug-gnu-emacs@m.gmane.org; Thu, 01 Mar 2018 06:44:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1erMLb-0005ZU-Kg for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 06:26:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1erMLa-0000Nb-Ap for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 06:26:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58599) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1erMLa-0000NW-6n for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 06:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1erMLZ-00013b-Tq for bug-gnu-emacs@gnu.org; Thu, 01 Mar 2018 06:26:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Mar 2018 11:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30626 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30626-submit@debbugs.gnu.org id=B30626.15199035544049 (code B ref 30626); Thu, 01 Mar 2018 11:26:01 +0000 Original-Received: (at 30626) by debbugs.gnu.org; 1 Mar 2018 11:25:54 +0000 Original-Received: from localhost ([127.0.0.1]:38262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erMLS-00013F-48 for submit@debbugs.gnu.org; Thu, 01 Mar 2018 06:25:54 -0500 Original-Received: from mout.web.de ([212.227.17.12]:39465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1erMLP-000131-R4 for 30626@debbugs.gnu.org; Thu, 01 Mar 2018 06:25:52 -0500 Original-Received: from drachen.dragon ([188.99.169.170]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MEmgA-1exOjq0v1O-00G584; Thu, 01 Mar 2018 12:25:44 +0100 In-Reply-To: <87lgfdnf86.fsf@web.de> (Michael Heerdegen's message of "Wed, 28 Feb 2018 19:25:45 +0100") X-Provags-ID: V03:K0:ZA3UyJrqrPYXyGGH6nkUim5onRakIxD7uo7ZlAFiMl5lZVvqLkI gwNnEZ4gzk4nNZ2vIkiD56E+Xe68ymt5YphYli7fEbLmX1b/LpO9MLG7FnVl2Mdi68m1OQ5 6jLVq+/3B36Xt0SPyfke/8l0mQMQJn6T8zs9XM+dnkflUKuEQ5Do3sqkdYT/dru9WEjn2PT ZDDnVQu/ll6NbwdoW0bog== X-UI-Out-Filterresults: notjunk:1;V01:K0:pixoC40cy78=:1khWpvoXDTEKOgOQZBuVQr 3XbXhZNRqFzyTfb4NwgsGwJSF1zaf+YPHgR1lD16ex7Vo1FWY2k2kQ7QPq33oKszVngVYE/jQ PPMtQU2FYt+5T/x7et5E+XSB2rc1hhw4Ky9/n0Lo1AItd1LZ15kQOF9dLiPAfzMXV3f3ZFYf+ 1Hy8nN5MPRlnyA8iSrQwBLUtWWVGBmhLHWAyE/A4fQQp09fW9NhtWpLNwP6w5q2sy7TLxAE9B gTVYZQOftPJjoKM2xkku8+OX3osXmwMcuZjDnVJFWfOuYkpSCE8HhPIZkQBEVyhSs4s6H+toV 5zC8jjjj34ny5PqaHn0zZ5AZXSRLushH8jXnw30QiH8+0/G1rgVj2GkTktNlC1zKMGRz3O22Y WlzT9RKR0Y8n3Fqey/DHwwbEB4JT7zoYxqMUTE1Zn9Q4q44SDHHoHmg9sBKzl1Nw918139lrP nW+z9vMucDSW7fO5mH69JG48rK1T1dtZZ5gklnF9wL5ZUNAujLskh3GKzDQyVsfyiFqweyu1Z iU5dwaElCznD4EFWA9I7ER14IrSKPzzaUKdVitBvO21iW80zdxEksTYaVUeYkVB6jETJrjf69 NXYeLCFuMhqTL6FPzNf1pXgZSf5ttBDC943/K6wJAJ31vbVvJlPkUevW3g9lL0fQZ32KSFzbi aKx3VllAVLUbcV2OsfI8yj8PXY4FTl3UX+CprFbhwEb3wyn70MU1qpkByskiHwZ4jSZRvh/sI 9JPoACVNoYpm/6mztu+BMiXRuwxw0iN4j+s7rc7lodof6U8bG7mA7irBt2p6/zFwgvwc5ZeN X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:143780 Archived-At: Michael Heerdegen writes: > The inner `stream-range' call results in a closure, and I guess that > this closure includes a reference to the outside VAL, which is the > stream from one step back (though there isn't a lexical reference to the > variable...does that make sense?) This is probably only a part of the puzzle. Some examples: test1.el: This is more or less the `stream-range' example reimplemented without dependencies so that it works in emacs -Q: #+begin_src emacs-lisp ;; -*- lexical-binding: t -*- (defun my-range (start) (let (forced val) (lambda () (unless forced (setq val (cons start (my-range (1+ start))) forced t)) val))) (defun my-test () (let ((range-object (my-range 1)) current-cons) (while (< (car (setq current-cons (funcall range-object))) (* 1000 1000)) (message "%d" (car current-cons)) (setq range-object (cdr current-cons))))) (my-test) #+end_src Loading this file test1.el crashes Emacs - but if you compile it, loading the compiled file doesn't crash. This is what I expected from my previous thoughts, because only the uncompiled closures include a reference to the outer VALs. test2.el: #+begin_src emacs-lisp ;; -*- lexical-binding: t -*- (require 'stream) (let ((stream (stream-range 1 1000000))) (stream-flush stream)) #+end_src This traverses the whole stream ignoring the elements. Loading this file crashes Emacs, no matter if compiled or not. I'm surprised it doesn't work even when compiled. test3.el: #+begin_src emacs-lisp ;; -*- lexical-binding: t -*- (require 'stream) (let ((stream (stream-range 1 1000000))) (while (not (stream-empty-p stream)) (cl-callf stream-rest stream))) #+end_src This is semantically exactly like test2.el, only the call to `stream-flush' has been replaced by literally writing out the definition. Nonetheless, the compiled file suddenly doesn't crash Emacs when loaded. Loading the uncompiled file test3.el still crashes. Seems that whether we get a crash or not depends on details in the implementation of lexical-binding. Michael.