Re: DJGPP only dumps with USE_LISP_UNION_TYPE ??

["Jan D." <jan.h.d@swipnet.se>]

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.