bug#11867: 24.1.50; Windows bootstrap crash (converting tit files?)

[Eli Zaretskii <eliz@gnu.org>]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 13 Jul 2012 02:13:11 +0200
> Cc: rcopley@gmail.com, 11867@debbugs.gnu.org
> 
> emacs.exe caused an Access Violation at location 012e09bf in module
> emacs.exe Reading from location 058d7018.
> 
> Registers:
> eax=058d7000 ebx=056fc880 ecx=00000000 edx=056fc260 esi=03e8d31c edi=03846d1e
> eip=012e09bf esp=0088d1f0 ebp=0088d218 iopl=0         nv up ei pl nz na po nc
> cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

What does the following display?

 cd src
 gdb ./oo/i386/emacs.exe
 (gdb) list *0x012e09bf

To give accurate information, the emacs.exe you submit to GDB must be
the same emacs.exe for which you have the DrMinGW report showing the
crash location above.

> Call stack:
> AddrPC     AddrReturn AddrFrame  AddrStack  Params
> 012E09BF   012E0EF9   0088D218   0088D1F0   056FC880   03E8D200
> 0088D258   010AE3CF

For each of the call stack frames, you should be able to reconstruct
their source-level locations by "list *0xADDRESS", where ADDRESS is
the number in the AddrPC column.  It's a bit tedious, but it gets the
job done.

> 012E09BF  emacs.exe:012E09BFC:\emacs\debug\src\oo\i386\emacs.exe: No
> symbol found

I guess DrMinGW no longer understands the symbol table produced by
GCC 4.x; with my GCC 3.4.x it produces source level information
automatically.