[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??

From: Jan D.
Subject: Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??
Date: Mon, 08 Nov 2004 21:40:35 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707

Eli Zaretskii wrote:

d:/djgpp/bin/ld.exe: temacs: warning: .text: line number overflow: 0x11102 > 

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:


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 

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]