From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#2099: 23.0.60; `mark_object' with larger nested objects crashes Emacs Date: Mon, 11 Jan 2016 22:32:52 +0200 Message-ID: <83si23kgaz.fsf@gnu.org> References: <20090128230645.07F1DC468CC@mt-computer.local> <83vb70kv67.fsf@gnu.org>, , <8337u4kju1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1452544466 24141 80.91.229.3 (11 Jan 2016 20:34:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Jan 2016 20:34:26 +0000 (UTC) Cc: alan@idiocy.org, larsi@gnus.org, 2099@debbugs.gnu.org To: markus.triska@gmx.at Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 11 21:34:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1aIjAL-00055L-C2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jan 2016 21:34:13 +0100 Original-Received: from localhost ([::1]:56805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIjAK-0005Yc-Jm for geb-bug-gnu-emacs@m.gmane.org; Mon, 11 Jan 2016 15:34:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIjAE-0005W0-51 for bug-gnu-emacs@gnu.org; Mon, 11 Jan 2016 15:34:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIjAA-0005VE-Fy for bug-gnu-emacs@gnu.org; Mon, 11 Jan 2016 15:34:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58618) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIjAA-0005V2-Co for bug-gnu-emacs@gnu.org; Mon, 11 Jan 2016 15:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aIjAA-0004p9-6E for bug-gnu-emacs@gnu.org; Mon, 11 Jan 2016 15:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Jan 2016 20:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 2099 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 2099-submit@debbugs.gnu.org id=B2099.145254439218469 (code B ref 2099); Mon, 11 Jan 2016 20:34:02 +0000 Original-Received: (at 2099) by debbugs.gnu.org; 11 Jan 2016 20:33:12 +0000 Original-Received: from localhost ([127.0.0.1]:46835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aIj9L-0004no-Re for submit@debbugs.gnu.org; Mon, 11 Jan 2016 15:33:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41398) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aIj9H-0004na-En for 2099@debbugs.gnu.org; Mon, 11 Jan 2016 15:33:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aIj98-0005G5-La for 2099@debbugs.gnu.org; Mon, 11 Jan 2016 15:33:02 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aIj8x-0005C4-JW; Mon, 11 Jan 2016 15:32:47 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3050 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aIj8w-0006tp-HU; Mon, 11 Jan 2016 15:32:47 -0500 In-reply-to: (markus.triska@gmx.at) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:111528 Archived-At: > From: markus.triska@gmx.at > Cc: alan@idiocy.org, 2099@debbugs.gnu.org, larsi@gnus.org > Date: Mon, 11 Jan 2016 20:57:49 +0100 > > > Sorry, I don't understand: what testing? Can you describe the > > real-life use case behind this bug report? The recipe as shown looks > > like a deliberate way to cause Emacs to overflow its stack; surely, > > that's not what you intended to test? > > That's not what I intended to test: Emacs crashing on such datastructures > prevents more serious automatic tests that can, among other data, also > create such structures. I'm asking to describe the data structures that you intended to test, and their purpose. The recipe that you posted when you filed the bug conses an infinitely large object in an infinite loop. Can you please tell what is the purpose of creating such a data structure in this way? It's clear that at some point Emacs will run out of memory, and it is also clear that at some other point it will GC. So what is being tested by such a data structure, given that these outcomes are known in advance? > So far, this shortcoming has prevented my working further on such > tests. Knowing more about those tests might help us become more motivated to work on the problems that interfere with your testing, or suggest how to work around them. > I find it hard to believe that a way to crash Emacs is somehow *not* > considered a bug. There could be many ways to overcome these problems, some of them easier than others. It all depends on what problems get in your way. For example, there could be a way of letting Emacs run out of heap memory without triggering GC -- would that help you continue with your testing? I don't know, maybe you could tell. IOW, if there are practical issues for which you'd like to have a solution or a workaround, so that you could continue with your testing, we could try helping you on that way. I'm sure you agree that leaving the bug without any action will not help you make any progress with your project. Please help us help you in any practical way that's possible, by telling more about the specific aspects of Emacs you'd like to test. > If that is the case, I agree with what Glenn recently said: Just > deal with this report in any way you wish. Relax, no one said this isn't a bug, so this is uncalled for. I'm just trying to understand what is being tested here. I couldn't understand that from the recipe you posted, because that recipe has an outcome that's known in advance.