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#22526: 25.0.90; Crash starting gnus Date: Thu, 11 Feb 2016 22:27:23 +0200 Message-ID: <8360xv9ems.fsf@gnu.org> References: <56AFD88B.5040904@gmail.com> <87pow9cc0c.fsf@gnus.org> <83h9hkse78.fsf@gnu.org> <864mdk44q6.fsf@gmail.com> <83mvrcqli1.fsf@gnu.org> <86twlg2e69.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455222505 16388 80.91.229.3 (11 Feb 2016 20:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 11 Feb 2016 20:28:25 +0000 (UTC) Cc: 22526@debbugs.gnu.org To: Andy Moreton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 11 21:28:14 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 1aTxqX-0003om-1Q for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Feb 2016 21:28:13 +0100 Original-Received: from localhost ([::1]:53309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTxqW-0005pF-Cj for geb-bug-gnu-emacs@m.gmane.org; Thu, 11 Feb 2016 15:28:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTxqR-0005lD-Cb for bug-gnu-emacs@gnu.org; Thu, 11 Feb 2016 15:28:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTxqM-0005Go-CV for bug-gnu-emacs@gnu.org; Thu, 11 Feb 2016 15:28:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTxqM-0005Gk-8n for bug-gnu-emacs@gnu.org; Thu, 11 Feb 2016 15:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aTxqM-000097-2X for bug-gnu-emacs@gnu.org; Thu, 11 Feb 2016 15:28: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: Thu, 11 Feb 2016 20:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22526 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22526-submit@debbugs.gnu.org id=B22526.1455222463529 (code B ref 22526); Thu, 11 Feb 2016 20:28:02 +0000 Original-Received: (at 22526) by debbugs.gnu.org; 11 Feb 2016 20:27:43 +0000 Original-Received: from localhost ([127.0.0.1]:36960 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTxq3-00008T-63 for submit@debbugs.gnu.org; Thu, 11 Feb 2016 15:27:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41715) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTxq1-000085-Kw for 22526@debbugs.gnu.org; Thu, 11 Feb 2016 15:27:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTxpr-0005Ee-DS for 22526@debbugs.gnu.org; Thu, 11 Feb 2016 15:27:36 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTxpr-0005EZ-9x; Thu, 11 Feb 2016 15:27:31 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4924 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aTxpq-0004N7-Kq; Thu, 11 Feb 2016 15:27:31 -0500 In-reply-to: <86twlg2e69.fsf@gmail.com> (message from Andy Moreton on Thu, 11 Feb 2016 02:06:54 +0000) 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:112899 Archived-At: > From: Andy Moreton > Date: Thu, 11 Feb 2016 02:06:54 +0000 > > Hopefully this is of some use. It is, thanks. The plot thickens... This is one of those cases where I'd give anything for a way to trace execution in reverse and see what happened before the problem... Anyway, is that GDB session still running? If so, could you please try the following two GDB commands? (gdb) p Z_ADDR (gdb) p *(Z_ADDR) If the last one says something about not being able to access memory at address such-and-such, then please try a series of commands like this: (gdb) p/x *(Z_ADDR - 1) (gdb) p/x *(Z_ADDR - 2) (gdb) p/x *(Z_ADDR - 3) etc., until you find the largest address which GDB succeeds to access and report its contents. (If the first few commands still report failure to access, it might be better to use larger offsets, and then perform binary search once you find an accessible address.) The goal is, assuming that Z_ADDR somehow points to memory outside of the process address space, to find the last byte that is still inside the address space. Then do this: (gdb) p/x THAT_ADDRESS - BEG_ADDR where THAT_ADDRESS is the last address that GDB can access. I'd also like to ask you to add a couple of lines to make_gap_larger, to help with debugging this, but I want to see the results of the above first. For the record, what seems to have happened here is that some Gnus command caused Emacs to insert a 4K string into a buffer that was 63493 bytes long. In response, Emacs enlarged the buffer text to accommodate those 4K, then moved the existing buffer text towards higher address to enlarge the gap by 4K, in preparation for inserting the string into the gap. Then it crashed when it tried to null-terminate the enlarged buffer text. The crash is strange because the code in gap_left, called just before the crash, should have already accessed all the addresses up to and including the one immediately preceding Z_ADDR. So this seems to imply that there's some off-by-one error somewhere in the related code, but I don't see it yet. Btw, it sounds like it should be easy to reproduce this almost at will, since the two backtraces are almost identical -- they both show the same insertion of a 4096 byte string into a buffer by the default process filter that reads stuff received from the news server. Could you perhaps try coming up with such a reproducer, starting from "emacs -Q"? That would make the debugging much more efficient. Thanks.