From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function Date: Tue, 16 Oct 2018 22:25:21 +0300 Message-ID: <83in21snha.fsf@gnu.org> References: <87d0sh9hje.fsf@runbox.com> <83murjwplq.fsf@gnu.org> <87zhvjc4r3.fsf@runbox.com> <83y3b2uzyt.fsf@gnu.org> <87va65daw9.fsf@runbox.com> <8336t9vi3h.fsf@gnu.org> <87ftx89uqs.fsf@igel.home> <837eijtfw1.fsf@gnu.org> <878t2xd90z.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1539717885 29967 195.159.176.226 (16 Oct 2018 19:24:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2018 19:24:45 +0000 (UTC) Cc: 33014@debbugs.gnu.org, schwab@linux-m68k.org To: Gemini Lasswell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 16 21:24:41 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 1gCUxN-0007hM-AA for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2018 21:24:41 +0200 Original-Received: from localhost ([::1]:59933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCUzT-0003q3-HG for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2018 15:26:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCUyn-0003Xl-Dm for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2018 15:26:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCUyh-0000fI-Pv for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2018 15:26:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49736) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gCUyg-0000d1-7O for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2018 15:26:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gCUyf-00008p-SH for bug-gnu-emacs@gnu.org; Tue, 16 Oct 2018 15:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Oct 2018 19:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33014 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33014-submit@debbugs.gnu.org id=B33014.1539717933495 (code B ref 33014); Tue, 16 Oct 2018 19:26:01 +0000 Original-Received: (at 33014) by debbugs.gnu.org; 16 Oct 2018 19:25:33 +0000 Original-Received: from localhost ([127.0.0.1]:53994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCUyB-00007s-D8 for submit@debbugs.gnu.org; Tue, 16 Oct 2018 15:25:31 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCUy9-00007c-1g for 33014@debbugs.gnu.org; Tue, 16 Oct 2018 15:25:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCUxr-00083Z-D6 for 33014@debbugs.gnu.org; Tue, 16 Oct 2018 15:25:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCUxr-00082l-4S; Tue, 16 Oct 2018 15:25:11 -0400 Original-Received: from [176.228.60.248] (port=3723 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gCUxq-0008DS-JO; Tue, 16 Oct 2018 15:25:11 -0400 In-reply-to: <878t2xd90z.fsf@runbox.com> (message from Gemini Lasswell on Tue, 16 Oct 2018 11:46:36 -0700) 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" Xref: news.gmane.org gmane.emacs.bugs:151320 Archived-At: > From: Gemini Lasswell > Cc: Andreas Schwab , 33014@debbugs.gnu.org > Date: Tue, 16 Oct 2018 11:46:36 -0700 > > My knowledge of what gcc does and how the code it generates works is > superficial, but I don't see why an optimizer would find it necessary to > save the following values: > > - The value of 'fun' in Ffuncall after it is used as an argument for > funcall_lambda. > > - The value of 'fun' in funcall_lambda after it is used to calculate > the arguments to exec_byte_code. > > - The value of 'vector' in exec_byte_code after the calculation of > vectorp. There are calling frames as well. For GC to pay attention to a Lisp object, it is enough to have that object _somewhere_ on the stack. Anyway, are you saying that stack marking doesn't work in optimized code? We've been using this technique for the last 17 years without problems; why would the fact that we have more than one thread change that? The same arguments you submit are valid for a single-threaded Emacs, right? I think the chance of something like what you describe to happen here are small, and we shouldn't throw in the towel so quickly. I don't think we've exhausted all the other possibilities, not yet. > gdb shows a value for fun in frame 11, but when I try to print > XIL(0x7fecdacdc468) it complains about it being an invalid lisp object, > and then the result of "info frame 11" shows some similar values, > so I'm thinking gdb is confused: It's quite possible that GDB is not confused, and you've found some evidence of the problem. How did you try to print XIL(0x7fecdacdc468)? Maybe we should take a good look at this object. > I haven't figured out how to get gdb to print the Lisp backtrace of one > thread while execution is stopped in a different one. You can't, AFAIR. The code that helps us produce a Lisp backtrace doesn't work in that case.