From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs Subject: bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function Date: Fri, 12 Oct 2018 13:02:56 -0700 Message-ID: <87zhvjc4r3.fsf@runbox.com> References: <87d0sh9hje.fsf@runbox.com> <83murjwplq.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1539374524 23301 195.159.176.226 (12 Oct 2018 20:02:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2018 20:02:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: 33014@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Oct 12 22:01:59 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 1gB3dH-0005v2-E3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2018 22:01:59 +0200 Original-Received: from localhost ([::1]:42446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gB3fN-0007TQ-Se for geb-bug-gnu-emacs@m.gmane.org; Fri, 12 Oct 2018 16:04:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gB3fI-0007TK-1Y for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2018 16:04:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gB3fG-0000Mz-LW for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2018 16:04:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:43235) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gB3fG-0000Mj-H8 for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2018 16:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gB3fG-00061W-7l for bug-gnu-emacs@gnu.org; Fri, 12 Oct 2018 16:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Oct 2018 20:04:02 +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.153937462023128 (code B ref 33014); Fri, 12 Oct 2018 20:04:02 +0000 Original-Received: (at 33014) by debbugs.gnu.org; 12 Oct 2018 20:03:40 +0000 Original-Received: from localhost ([127.0.0.1]:47493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gB3et-00060y-Oi for submit@debbugs.gnu.org; Fri, 12 Oct 2018 16:03:40 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:35416) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gB3er-00060q-TU for 33014@debbugs.gnu.org; Fri, 12 Oct 2018 16:03:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Transfer-Encoding:Content-Type:MIME-Version: Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=TaTW4OXtzPleDtvRehRKo0LrW2dQhBha4y7q8t1TG/M=; b=jPPt6xUXMSH4N7JDrvIWBz9uie 8lG2UEdTtkJymnL9jRBOKST8xH9zX4dEfv9G8m00iQKGwQNVp9ICjVi1m5wGK8T7ggVwh55Dup8wk fg3XfFg/Hjpj6LWHZH4p4LeVZ/w/PiDkJPxODCS6V/fQGyUvpPB5LK/i4mwMDAvlTOjMfpN5yGTuT Md8G1nTXjvMEUGqZ+QzzwvTa5p7etsb71k53YELZWe4/6J3O6zVbYwMt2d5nFY/mPBiAPyRHwo60X 2SRLkDy9LdPj3VyVubxRa7KhsNeYgXs6p0yQ8OVZvHM1Z1n7RZdjbjBR3NrjBXzsJEmj6y8vtgN3U yd90uPZA==; Original-Received: from [10.9.9.211] (helo=mailfront11.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gB3eq-00053A-Re; Fri, 12 Oct 2018 22:03:36 +0200 Original-Received: by mailfront11.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gB3eG-0000Br-Of; Fri, 12 Oct 2018 22:03:01 +0200 In-Reply-To: <83murjwplq.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Oct 2018 11:12:17 +0300") 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:151188 Archived-At: Eli Zaretskii writes: > Can you please make a smaller stand-alone test case, which doesn't > require patching Emacs? That will make it much easier to try > reproducing the problem. I've tried to do that without success. The bug won't reproduce if I put all the code added to thread.el by the patch into its own file and load it with C-u M-x byte-compile-file, and it also doesn't work to put the resulting .elc on my load-path and load it with require. I've determined today that having -O2 in CFLAGS is necessary to reproduce the bug, and that -O1 or -O0 won't do it. > Can you show the Lisp backtrace of this thread? Also, what is the > offending object 'a' in this frame: The Lisp backtrace is really short: Thread 7 (Thread 0x7f1cd4dec700 (LWP 21837)): "erb--benchmark-monitor-func" (0x158ec58) >> #2 0x00000000006122b5 in XHASH_TABLE (a=3D...) at lisp.h:2241 > > and what was its parent object in the calling frame? Those are both optimized out with -O2. I recompiled bytecode.c with "volatile" on the declaration of jmp_table, and got this: (gdb) up 3 #3 exec_byte_code (bytestr=3D..., vector=3D..., maxdepth=3D..., args_templ= ate=3D...,=20 nargs=3Dnargs@entry=3D0, args=3D,=20 args@entry=3D0x16eacf8 ) at bytecode.c:1403 1403 struct Lisp_Hash_Table *h =3D XHASH_TABLE (jmp_table); (gdb) p jmp_table $1 =3D make_number(514) (gdb) p *top $3 =3D XIL(0x42b4d0) (gdb) pp *top remove Then I started looking at other variables in exec_byte_code, and found this which didn't look right: (gdb) p *vectorp $13 =3D XIL(0x7f4934009523) (gdb) pr (((help-menu "Help" keymap (emacs-tutorial menu-item "Emacs Tutorial" help-= with-tutorial :help "Lear ?\207" [yank-menu kill-ring buffer-read-only gui-backend-selection-exists-p= CLIPBOARD featurep ns] 2 \205^Q^@=C3=85=C3=86!\207" [visual-line-mode word-wrap truncate-lines 0 nil= toggle-truncate-lines -1] 2 nil ni (I've truncated the result of printing *vectorp since each line is over 5000 characters long.) Since that looked like it was unlikely to be the original value of *vectorp, I started a new debugging session and stepped through Thread 7's call to exec_byte_code for erb--benchmark-monitor-func, and determined that *vectorp's initial value was erb--status-updates, which matches the first element of the constants vector in (symbol-function 'erb--benchmark-monitor-func). The value of vectorp was 0x16eac38 so I set a watchpoint on *(EMACS_INT *) 0x16eac38 and continued, and then during the execution of eval-region it triggered here: Thread 1 "monitor" hit Hardware watchpoint 7: *(EMACS_INT *) 0x16eac38 Old value =3D 60897760 New value =3D 24075314 setup_on_free_list (v=3Dv@entry=3D0x16eac30 ,=20 nbytes=3Dnbytes@entry=3D272) at alloc.c:3060 3060 total_free_vector_slots +=3D nbytes / word_size; (gdb) bt 10 #0 setup_on_free_list (v=3Dv@entry=3D0x16eac30 ,= =20 nbytes=3Dnbytes@entry=3D272) at alloc.c:3060 #1 0x00000000005a9a24 in sweep_vectors () at alloc.c:3297 #2 0x00000000005adb2e in gc_sweep () at alloc.c:6872 #3 garbage_collect_1 (end=3D) at alloc.c:5860 #4 Fgarbage_collect () at alloc.c:5989 #5 0x00000000005ca478 in maybe_gc () at lisp.h:4804 #6 Ffuncall (nargs=3D4, args=3Dargs@entry=3D0x7fff210a3bc8) at eval.c:2838 #7 0x0000000000611e00 in exec_byte_code (bytestr=3D..., vector=3D..., maxd= epth=3D...,=20 args_template=3D..., nargs=3Dnargs@entry=3D2, args=3D,=20 args@entry=3D0x9bd128 ) at bytecode.c:632 #8 0x00000000005cdd32 in funcall_lambda (fun=3DXIL(0x7fff210a3bc8),=20 nargs=3Dnargs@entry=3D2, arg_vector=3D0x9bd128 ,=20 arg_vector@entry=3D0x7fff210a3f00) at eval.c:3057 #9 0x00000000005ca54b in Ffuncall (nargs=3D3, args=3Dargs@entry=3D0x7fff21= 0a3ef8) at eval.c:2870 (More stack frames follow...) Note that just as was happening when we were working through bug#32357, the thread names which gdb prints are wrong, which I verified with: (gdb) p current_thread $21 =3D (struct thread_state *) 0xd73480 (gdb) p current_thread->name $22 =3D XIL(0) Am I correct that the next step is to figure out why the garbage collector is not marking this vector? Presumably it's no longer attached to the function definition for erb--benchmark-monitor-func by the time the garbage collector runs, but it's supposed to be found by mark_stack when called from mark_one_thread for Thread 7, right?