From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: DJGPP only dumps with USE_LISP_UNION_TYPE ?? Date: Mon, 08 Nov 2004 21:40:35 +0100 Message-ID: <418FD9C3.7080507@swipnet.se> References: <01c4c514$Blat.v2.2.2$ca305740@zahav.net.il> <418EB423.9030601@swipnet.se> <01c4c56a$Blat.v2.2.2$96dd3060@zahav.net.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099946517 22179 80.91.229.6 (8 Nov 2004 20:41:57 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Nov 2004 20:41:57 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 08 21:41:47 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CRGKg-0003DY-00 for ; Mon, 08 Nov 2004 21:41:47 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CRGT2-0004P6-EB for ged-emacs-devel@m.gmane.org; Mon, 08 Nov 2004 15:50:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CRGSu-0004P0-Gj for emacs-devel@gnu.org; Mon, 08 Nov 2004 15:50:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CRGSu-0004Oo-3Y for emacs-devel@gnu.org; Mon, 08 Nov 2004 15:50:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CRGSu-0004Ol-0R for emacs-devel@gnu.org; Mon, 08 Nov 2004 15:50:16 -0500 Original-Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CRGK9-0004jp-1u; Mon, 08 Nov 2004 15:41:13 -0500 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep01.bredband.com with ESMTP id <20041108204110.MQPC4883.mxfep01.bredband.com@coolsville.localdomain>; Mon, 8 Nov 2004 21:41:10 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: sv, en-us, en Original-To: Eli Zaretskii In-Reply-To: <01c4c56a$Blat.v2.2.2$96dd3060@zahav.net.il> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:29598 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29598 Eli Zaretskii wrote: >> >>d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 0xffff > > > This warning is harmless. It is printed by ld because Emacs is > compiled with COFF debug info (the -gcoff option to GCC; I never got > to making unexec work for DJGPP with the DWARF-2 debug info), and COFF > debug info cannot have more than 64K source-line records, the > structures that tell the debugger what is the address of each source > line in the binary. > > Are you saying that building with USE_LSB_TAG undefined does not > produce this warning? That would be extremely strange, as I don't > think the build without USE_LSB_TAG can reduce the number of source > lines by 1103 hex (=4355 decimal) lines, which is the difference > between 0x11102 and 0xffff. Yes, this is the case. > > >>The OS is MS Windows XP, service pack 1. > > > This is one difference between us: I never tried to build on an XP > machine; mine runs Windows 98. Please be sure to download and install > the latest version of djdev203.zip from this site: > > ftp://ftp.delorie.com/pub/djgpp/current/v2/djdev203.zip That was the version I have (did a cmp). >>In file included from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24: >>../src/config.h:1121:1: warning: "bzero" redefined >>In file included from ../src/config.h:1055, >> from D:/SRC/EMACS/LIB-SRC/test-distrib.c:24: >>d:/djgpp/include/string.h:55:1: warning: this is the location of the previous definition > > > This is an annoyance (I fixed it locally for me a long time ago, but > now I see my fix is not good for others). I will fix that now in a > better way in the Emacs CVS; stay tuned. Again, I don't think it's > relevant to your problem, but perhaps it could explain why I don't see > the bug. Hmm... This annoyance is gone now, thanks. > Hmm.. sounds like a real bug, which somehow doesn't happen for me. I > will try several things to reproduce it, but in the meanwhile, please > try to debug the crash using the guidelines in etc/DEBUG (under > "Debugging problems which happen in GC"), as from the debug session > you posted earlier it looked like a real integer crept into a Lisp > object, i.e. somewhere we don't call make_number or something. Please > try to find out what Lisp data structure is being marked at the point > of the crash; when we know that, a simple search through sources > should pinpoint the offender. > > Note that hardware-assisted breakpoints and watchpoints don't work on > XP in the DJGPP port of GDB (due to a bug in the XP implementation of > the DPMI spec), so don't try to use hbreak and watch commands. (What > version of GDB do you have installed, btw?) GDB 6.1.1. The variable it craches on is Vbuffer_local_symbols (I found out that earlier). I don't think a real integer was inserted, but the data has been corrupted. For example. the array size of Vbuffer_local_symbols is 3305473. I don't think that is reasonable. last_marked didn't give any useful information. I looked at the 70 last marked objects, there where mainly zeros, with a couple of Qt and Qnil here and there. Stefan wrote: > To debug problems related to USE_LSB_TAG, the first thing to do is to > use -DENABLE_CHECKING. Of course it doesn't always help, It does in this case: Emacs fatal error: buffer.c:4944: assertion failed: XTYPE (&buffer_defaults) == 0 In gdb I see that &buffer_local_symbols which is what Vbuffer_local_symbols uses, isn't aligned to an even 8 either. These are aligned to an even 4. So DECL_ALIGN isn't working in this configuration (?). Sounds strange. Jan D.