From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Vivek Dasmohapatra Newsgroups: gmane.emacs.bugs Subject: bug#26932: 25.1; Crash triggered a few times a day with network process Date: Mon, 19 Jun 2017 01:57:54 +0100 (BST) Message-ID: References: <83bmqu7rdd.fsf@gnu.org> <83h8zl5mag.fsf@gnu.org> <831sqp5hn3.fsf@gnu.org> <83zidd4196.fsf@gnu.org> <83bmpr4z7s.fsf@gnu.org> <8337b34qnw.fsf@gnu.org> <83zidb2t9o.fsf@gnu.org> <83d1a52tq6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2143677985-1497833875=:17706" X-Trace: blaine.gmane.org 1497833900 30724 195.159.176.226 (19 Jun 2017 00:58:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Jun 2017 00:58:20 +0000 (UTC) User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Cc: 26932@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 19 02:58:13 2017 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 1dMl1B-0007am-5n for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jun 2017 02:58:13 +0200 Original-Received: from localhost ([::1]:40051 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMl1G-00035l-5e for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Jun 2017 20:58:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMl13-00035f-G2 for bug-gnu-emacs@gnu.org; Sun, 18 Jun 2017 20:58:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMl10-0000T0-EO for bug-gnu-emacs@gnu.org; Sun, 18 Jun 2017 20:58:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52795) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dMl10-0000Sw-A6 for bug-gnu-emacs@gnu.org; Sun, 18 Jun 2017 20:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dMl10-0006Uk-0f for bug-gnu-emacs@gnu.org; Sun, 18 Jun 2017 20:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vivek Dasmohapatra Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Jun 2017 00:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26932 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26932-submit@debbugs.gnu.org id=B26932.149783387924958 (code B ref 26932); Mon, 19 Jun 2017 00:58:01 +0000 Original-Received: (at 26932) by debbugs.gnu.org; 19 Jun 2017 00:57:59 +0000 Original-Received: from localhost ([127.0.0.1]:55472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMl0x-0006UU-Fm for submit@debbugs.gnu.org; Sun, 18 Jun 2017 20:57:59 -0400 Original-Received: from ceres.etla.org ([85.119.82.193]:56139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMl0w-0006UK-IQ for 26932@debbugs.gnu.org; Sun, 18 Jun 2017 20:57:58 -0400 Original-Received: from platypus.pepperfish.net ([2a01:4f8:201:620f::2001]) by ceres.etla.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dMl09-0006bj-Oh; Mon, 19 Jun 2017 01:57:10 +0100 X-X-Sender: vivek@platypus.pepperfish.net In-Reply-To: <83d1a52tq6.fsf@gnu.org> X-Spam_score: -3.0 X-Spam_score_int: -29 X-Spam_bar: --- X-Spam_report: Spam detection software, running on the system "ceres.etla.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: > The faulty object would be a very important clue. Once we find that > out, we should look at how that object is created and modified. Not sure I'm doing this right, but here's what I have so far: SEGV @ #0 mark_object; alloc.c:6450 last_mark_index=12, therefore last_mark[11] must be what we are looking at. [...] Content analysis details: (-3.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES 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:133739 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-2143677985-1497833875=:17706 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > The faulty object would be a very important clue. Once we find that > out, we should look at how that object is created and modified. Not sure I'm doing this right, but here's what I have so far: SEGV @ #0 mark_object; alloc.c:6450 last_mark_index=12, therefore last_mark[11] must be what we are looking at. (gdb) p XTYPE(last_marked[11]) $41 = Lisp_Symbol (gdb) p XSYMBOL(last_marked[11]) $44 = (struct Lisp_Symbol *) 0x3c382c0 (gdb) p *XSYMBOL(last_marked[11]) Cannot access memory at address 0x3c382c0 which matches alloc.c:6540 which is inside a `case Lisp_Symbol:' section line that fails is: if (ptr->gcmarkbit) so we have a duff symbol? ============================================================================ #1 mark_object; alloc.c:6543 inside a case Lisp_Cons: mark_object (ptr->car); assuming this is the previous marked object: (gdb) p XTYPE(last_marked[10]) $45 = Lisp_Cons (gdb) p XCONS(last_marked[10]) $46 = (struct Lisp_Cons *) 0x2eaf810 (gdb) p *XCONS(last_marked[10]) $47 = {car = 50828624, u = {cdr = 48953347, chain = 0x2eaf803}} (gdb) p XTYPE(50828624) $49 = Lisp_Symbol (gdb) p *XSYMBOL(50828624) Cannot access memory at address 0x3c382c0 // curses, foiled again ============================================================================ #2 mark_maybe_object; alloc.c:4743 Not interesting: checks for alive-ness and calls mark_object ============================================================================ #3 mark_memory (end=0x7fffffffe218, start=); alloc.c:4895 for (pp = start; (void *) pp < end; pp += GC_POINTER_ALIGNMENT) { mark_maybe_pointer (*(void **) pp); mark_maybe_object (*(Lisp_Object *) pp); // ← this is the entry point } (gdb) p XTYPE(*(Lisp_Object *)pp) $63 = Lisp_Cons (gdb) p *XCONS(*(Lisp_Object *)pp) $65 = {car = 48892595, u = {cdr = 49727219, chain = 0x2f6c6f3}} This doesn't seem to match what we encounter two frames down in mark_object: Maybe I've misinterpreted something? Anyway: following the earlier call to mark_maybe_pointer: (gdb) call mem_find(*((void **) pp)) $86 = (struct mem_node *) 0x2cce8a0 (gdb) p *(struct mem_node *) 0x2cce8a0 $87 = {left = 0x2cce8e0, right = 0x2e816e0, parent = 0x2d5cb00, start = 0x2f6c400, end = 0x2f6c7f0, color = MEM_BLACK, type = MEM_TYPE_CONS} and later on: case MEM_TYPE_CONS: if (live_cons_p (m, p) && !CONS_MARKED_P ((struct Lisp_Cons *) p)) XSETCONS (obj, p); break; so we've copied the cons cell into obj (I think). And then finally: if (!NILP (obj)) mark_object (obj); so maybe last_marked[9] is involved? idx 9 seems to be a list with every car being: (gdb) p last_marked[9] $120 = 48953379 (gdb) p XTYPE(last_marked[9]) $121 = Lisp_Cons (gdb) p *XCONS(last_marked[9]) $122 = {car = 8760836, u = {cdr = 48953363, chain = 0x2eaf813}} (gdb) p XTYPE(8760836) $123 = Lisp_String (gdb) p *XSTRING(8760836) $124 = {size = 4, size_byte = -1, intervals = 0x0, data = 0xb374bb "DEAD"} So... a reaped list? Not helpful anyway. Nothing identifiable here. ============================================================================ #4 mark_stack Nothing of note here ============================================================================ Going up the backtrace all I find is that we're in the modeline display code and we're _about_ to eval the mode-line-frame-identification value: (:eval (mode-line-frame-control)) But GC happens before we actually call it. Not sure where to go from here: Any advice? --8323329-2143677985-1497833875=:17706--