From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#39962: 27.0.90; Crash in Emacs 27.0.90 Date: Mon, 16 Mar 2020 17:07:12 +0200 Message-ID: <83fte8baov.fsf@gnu.org> References: <24162.58107.725366.668639@cochabamba.vanoostrum.org> <83y2s48yn7.fsf@gnu.org> <83zhck6obg.fsf@gnu.org> <83r1xv73ze.fsf@gnu.org> <83imj5bdct.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="38850"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39962@debbugs.gnu.org, eggert@cs.ucla.edu, pipcet@gmail.com To: Pieter van Oostrum Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 16 18:14:48 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jDtKB-0009wy-SV for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Mar 2020 18:14:47 +0100 Original-Received: from localhost ([::1]:43382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDtKA-0004up-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Mar 2020 13:14:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45158) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jDrLX-0006uM-Vv for bug-gnu-emacs@gnu.org; Mon, 16 Mar 2020 11:08:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jDrLW-0003w6-Ny for bug-gnu-emacs@gnu.org; Mon, 16 Mar 2020 11:08:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60029) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jDrLW-0003v4-IE for bug-gnu-emacs@gnu.org; Mon, 16 Mar 2020 11:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jDrLW-00013j-BW for bug-gnu-emacs@gnu.org; Mon, 16 Mar 2020 11:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Mar 2020 15:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39962 X-GNU-PR-Package: emacs Original-Received: via spool by 39962-submit@debbugs.gnu.org id=B39962.15843712504029 (code B ref 39962); Mon, 16 Mar 2020 15:08:02 +0000 Original-Received: (at 39962) by debbugs.gnu.org; 16 Mar 2020 15:07:30 +0000 Original-Received: from localhost ([127.0.0.1]:37769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDrL0-00012v-0X for submit@debbugs.gnu.org; Mon, 16 Mar 2020 11:07:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jDrKx-00012c-IF for 39962@debbugs.gnu.org; Mon, 16 Mar 2020 11:07:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jDrKr-0007uM-7p; Mon, 16 Mar 2020 11:07:21 -0400 Original-Received: from [176.228.60.248] (port=3899 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jDrKj-00079f-Te; Mon, 16 Mar 2020 11:07:20 -0400 In-Reply-To: (message from Pieter van Oostrum on Mon, 16 Mar 2020 11:44:40 +0100) 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: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:177415 Archived-At: > From: Pieter van Oostrum > Cc: 39962@debbugs.gnu.org, eggert@cs.ucla.edu, pipcet@gmail.com > Date: Mon, 16 Mar 2020 11:44:40 +0100 > > #3 0x00000001002b56e7 in mark_overlay (ptr=0x12c489030) at alloc.c:6213 > 6213 set_vectorlike_marked (&XMARKER (ptr->end)->header); > (gdb) p *ptr > $9 = { > header = { > size = -4611686018360274941 > }, > start = XIL(0x12c488fc5), > end = XIL(0), > plist = XIL(0x11dc4e263), > next = 0x12c488f30 > } > > So the end of the overlay = 0, and the size is negative. XIL(0) is not a position of zero, it's nil (which has binary representation as zero). IOW, the END marker of the overlay is nil, something that shouldn't happen. (The size prints negative because the object is marked, and the mark bit makes it look like a negative value.) And thus this abort is different from the one you reported originally: the failed assertion now says that something that should have been a marker, isn't. Is the START marker of that overlay valid (albeit marked)? If so, is its buffer live, i.e. is its name a Lisp string or is it nil? And if it's a live buffer, what kind of buffer is it? > Corruption. Maybe a stray assignment, or error in freeing memory. It does look like memory corruption, although it's hard to imagine a memory corruption that zeroes out one full 32-bit field of a struct, but leaves the previous one and the next one intact. > This build doesn't have the 0001-Don-t-collect-reachable-killed-buffers-during-GC.patch applied. I guess that patch might help. Didn't you say that an early version of that patch didn't help you avoid the crashes? But sure, go ahead and apply that patch, it cannot possibly hurt. Although the markers and the overlays are unlinked from the buffer as part of kill-buffer, i.e. before that patch comes into play... An alternative idea is to write code that checks overlays for nil markers, and then run this code periodically to find when such an overlay appears. Or maybe, given enough of such aborts, you could determine whether the offending overlay always belongs to a certain buffer, and then we could focus on monitoring that one buffer. Thanks.