From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: DJGPP only dumps with USE_LISP_UNION_TYPE ?? Date: Mon, 08 Nov 2004 10:10:43 +0200 Message-ID: <01c4c56a$Blat.v2.2.2$96dd3060@zahav.net.il> References: <01c4c514$Blat.v2.2.2$ca305740@zahav.net.il> <418EB423.9030601@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: sea.gmane.org 1099901864 17403 80.91.229.6 (8 Nov 2004 08:17:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 8 Nov 2004 08:17:44 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 08 09:17:30 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 1CR4iQ-0006jN-00 for ; Mon, 08 Nov 2004 09:17:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CR4ql-0005UW-2n for ged-emacs-devel@m.gmane.org; Mon, 08 Nov 2004 03:26:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CR4qd-0005U9-SQ for emacs-devel@gnu.org; Mon, 08 Nov 2004 03:25:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CR4qc-0005TK-1n for emacs-devel@gnu.org; Mon, 08 Nov 2004 03:25:58 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CR4qb-0005Su-Ld for emacs-devel@gnu.org; Mon, 08 Nov 2004 03:25:57 -0500 Original-Received: from [192.114.186.15] (helo=balder.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CR4hM-0002E9-QS for emacs-devel@gnu.org; Mon, 08 Nov 2004 03:16:25 -0500 Original-Received: from zaretski ([80.230.149.108]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DVW84052 (AUTH halo1); Mon, 8 Nov 2004 10:16:19 +0200 (IST) Original-To: "Jan D." X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 2.2.2 In-reply-to: <418EB423.9030601@swipnet.se> (jan.h.d@swipnet.se) 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:29557 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29557 > Date: Mon, 08 Nov 2004 00:47:47 +0100 > From: "Jan D." > CC: emacs-devel@gnu.org > > I checked out a fresh CVS as of 7 November, 23:50. The lisp files has > been compiled on GNU/Linux, with make recompile in lisp and then make > distclean. The tree was then copied to a dos disk on the same machine > and MS Windows was booted. That two-step GNU/Linux-Windows dance wasn't necessary, strictly speaking, since bootstrapping works in the DJGPP build (or at least it did when I last tried it, which, admittedly, was a while ago). But that is not really relevant to your problem. > I've attached two files, one with "config > msdos" output, and one with make output (I did not do any commands in > between). The make.txt file has been symified. Comparing these to the > ones with USE_LSB_TAG undef:ed shows one difference that might be > relevant. Not that I know what it means :-), but it occurs when temacs > is linked. > > 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. > 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 The other difference is the newer Binutils version you use, although you say that older versions caused the same trouble. > D:\src\emacs>config msdos > Checking whether 'sed' is available... > Checking whether 'rm' is available... > Checking whether 'mv' is available... > Checking whether 'gcc' is available... > Checking what version of DJGPP is installed... > Checking whether 'djecho' is available... > Configuring for DJGPP Version 2 ... > Configuring the source directory... > Configuring the library source directory... > Configuring the manual directory... > Configuring the ELisp manual directory... > Configuring the ELisp Introduction manual directory... > Configuring the lisp directory... > Configuring the leim directory... > Configuring the main directory... > Looking for the GDB init file... > File `src/_gdbinit' created > Looking for the GDB init file...found This is fine. > 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... > Loading international/mule... > Exiting due to signal SIGABRT > Raised at eip=00122e0e > eax=002b1ddc ebx=00000120 ecx=00000000 edx=00000000 esi=002c0001 edi=001368c0 > ebp=002b1e88 esp=002b1dd8 program=D:\src\emacs\src\temacs.exe > cs: sel=02a7 base=02c90000 limit=0035ffff > ds: sel=02af base=02c90000 limit=0035ffff > es: sel=02af base=02c90000 limit=0035ffff > fs: sel=027f base=0001c620 limit=0000ffff > gs: sel=02cf base=00000000 limit=0010ffff > ss: sel=02af base=02c90000 limit=0035ffff > App stack: [002b2878..00299878] Exceptn stack: [0029974c..0029780c] > > Call frame traceback EIPs: > 0x00122d34 ___djgpp_traceback_exit+48 > 0x00122e0e _raise+90 > 0x0010e28d _abort+45, line 0 of msdos.c > 0x000b2459 _mark_object+1801, line 5116 of alloc.c > 0x000b218f _mark_object+1087, line 4973 of alloc.c > 0x000b1b58 _Fgarbage_collect+1400, line 4457 of alloc.c 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?) Last, but not least, thanks for working on this.