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#12839: 24.3.50; Emacs aborts in GC Date: Fri, 09 Nov 2012 09:24:10 +0200 Message-ID: <83vcdfz1b9.fsf@gnu.org> References: <83625g10jw.fsf@gnu.org> <83zk2rzr6f.fsf@gnu.org> <509C7B1A.2070009@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1352445902 11058 80.91.229.3 (9 Nov 2012 07:25:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 9 Nov 2012 07:25:02 +0000 (UTC) Cc: 12839@debbugs.gnu.org To: Dmitry Antipov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 09 08:25:12 2012 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 1TWixj-0005Xd-ND for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Nov 2012 08:25:11 +0100 Original-Received: from localhost ([::1]:40908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWixa-00088R-HZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Nov 2012 02:25:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:47996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWixW-00086M-Vw for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 02:24:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TWixU-0005YT-MK for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 02:24:58 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46609) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TWixU-0005YF-IU for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 02:24:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TWixZ-0006i1-KE for bug-gnu-emacs@gnu.org; Fri, 09 Nov 2012 02:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Nov 2012 07:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12839 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 12839-submit@debbugs.gnu.org id=B12839.135244586525746 (code B ref 12839); Fri, 09 Nov 2012 07:25:01 +0000 Original-Received: (at 12839) by debbugs.gnu.org; 9 Nov 2012 07:24:25 +0000 Original-Received: from localhost ([127.0.0.1]:56860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWiwy-0006hC-HK for submit@debbugs.gnu.org; Fri, 09 Nov 2012 02:24:25 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:62007) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TWiwv-0006h3-2h for 12839@debbugs.gnu.org; Fri, 09 Nov 2012 02:24:22 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MD700E00LU0NY00@a-mtaout22.012.net.il> for 12839@debbugs.gnu.org; Fri, 09 Nov 2012 09:24:05 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MD700E22LW567Q0@a-mtaout22.012.net.il>; Fri, 09 Nov 2012 09:24:05 +0200 (IST) In-reply-to: <509C7B1A.2070009@yandex.ru> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.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:66662 Archived-At: > Date: Fri, 09 Nov 2012 07:40:10 +0400 > From: Dmitry Antipov > CC: 12839@debbugs.gnu.org > > Although I do my best to avoid platform-dependent tricks, some > things are platform-dependent anyway, like the DEFUN macro. If you > compile with Microsoft compiler, this is your case; I'm using GCC, not the Microsoft compiler. The MinGW development environment uses ported GNU utilities (GCC, Binutils, GDB, etc.) to compile native Windows programs. (If I were using MSVC, I couldn't have debugged programs with GDB, because GDB doesn't support the PDB debug info format emitted by the Microsoft compiler.) > can you use > gdb to dump any struct Lisp_Subr to see it's vectorlike_header? Is this what you wanted: (gdb) p Scons $6 = { header = { size = 1241513984 }, function = { a0 = 0x101a52e , a1 = 0x101a52e , a2 = 0x101a52e , a3 = 0x101a52e , a4 = 0x101a52e , a5 = 0x101a52e , a6 = 0x101a52e , a7 = 0x101a52e , a8 = 0x101a52e , aUNEVALLED = 0x101a52e , aMANY = 0x101a52e }, min_args = 2, max_args = 2, symbol_name = 0x1543375 "cons", intspec = 0x0, doc = 0xfff9849c
} (gdb) p *(struct vectorlike_header *)&(Scons.header) $7 = { size = 1241513984 } (gdb) p/x *(struct vectorlike_header *)&(Scons.header) $8 = { size = 0x4a000000 } > Also, if you suspect potentially bogus struct Lisp_Vector pointers, > please try xvectype and xvecsize gdb commands to get something > more informative than just the header->size shown as integer. Sorry, I'm not sure I understand: in the first backtrace I've shown, which was here (alloc.c:sweep_vectors): else { int tmp; SETUP_ON_FREE_LIST (vector, total_bytes, tmp); <<<<<<< } the vector in question is not a Lisp object, it is a pointer to 'struct Lisp_Vector': #2 0x0101b1a8 in sweep_vectors () at alloc.c:2864 2864 SETUP_ON_FREE_LIST (vector, total_bytes, tmp); (gdb) p vector $1 = (struct Lisp_Vector *) 0x38ae230 Maybe you meant this: (gdb) p *vector $2 = { header = { size = 1166225408 }, contents = {55859226} } (gdb) p vector->contents $3 = {55859226} (gdb) p vector->contents[0] $4 = 55859226 (gdb) xtype Lisp_Symbol (gdb) xsymbol $5 = (struct Lisp_Symbol *) 0x3545818 "nil" > > emacs -Q > > C-x 3 > > M-x set-variable RET auto-hscroll-mode RET nil RET > > I can't reproduce it on Linux, so it looks like the same > platform-dependent problem. I'd be happy to try debugging this myself, but I need guidance regarding some basics of what you changed recently in this area. Alternatively, tell me what to do in GDB, and I will post the results. I'm quite fluent with GDB, and reproducing this is extremely easy :-(. TIA