Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Mon, 08 Nov 2004 00:47:47 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> 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.