Re: bignum branch

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Sat, 11 Aug 2018 16:21:42 +0100
> 
> (gdb) bt full
> #0  0x00007ff83c63c903 in KERNELBASE!DebugBreak () from 
> C:\WINDOWS\System32\KernelBase.dll
> No symbol table info available.
> #1  0x000000040021d84d in emacs_abort () at 
> C:/emacs/git/emacs/bignum/src/w32fns.c:10775
>         button = <optimized out>
> #2  0x00000004000eff91 in terminate_due_to_signal (sig=0xb, 
> backtrace_limit=<optimized out>) at C:/emacs/git/emacs/bignum/src/emacs.c:399
> No locals.
> #3  0x0000000400110620 in handle_fatal_signal (sig=0xd60000, address@hidden) 
> at C:/emacs/git/emacs/bignum/src/sysdep.c:1769
> No locals.
> #4  0x00000004001102c8 in deliver_thread_signal (sig=0xb, handler=0x400110612 
> <handle_fatal_signal>) at C:/emacs/git/emacs/bignum/src/sysdep.c:1743
>         old_errno = 0x16
> #5  0x00000004001102e5 in deliver_fatal_thread_signal (sig=0xd60000) at 
> C:/emacs/git/emacs/bignum/src/sysdep.c:1781
> No locals.
> #6  0x000000040028610c in _gnu_exception_handler (exception_data=0xbfb890) at 
> C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:223
>         old_handler = <optimized out>
>         action = 0x0
>         reset_fpu = 0x0
> #7  0x00007ff83d0d7c58 in msvcrt!__C_specific_handler () from 
> C:\WINDOWS\System32\msvcrt.dll
> No symbol table info available.
> #8  0x00007ff83f86eced in ntdll!.chkstk () from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #9  0x00007ff83f7d6c86 in ntdll!RtlWalkFrameChain () from 
> C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #10 0x00007ff83f86dc1e in ntdll!KiUserExceptionDispatcher () from 
> C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #11 0x000000046ace5dc0 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> Lisp Backtrace:
> "logcount" (0xbfc7e0)
> "list" (0xbfc928)

Strange that it shows nothing before the exception handler.  Did you
run the test under GDB to begin with, or only attached it after the
abort dialog popped up?  If the latter, please run the test from GDB
to begin with (it is easier to do that if you run the test
interactively).

> Let me know if there is anything I should look for in gdb to try to
> debug this.

In case you already run the test from GDB: Is it true that logcount
always crashes in this build?  If so, can you step through logcount
and tell where exactly it crashes?  Once you determine the C line in
which it crashes, please re-run the test with a breakpoint inside
logcount, step through the function until you get to the crashing
line, and then use "stepi" to step into the function that crashes.
Please show the transcript of this stepping.

Thanks.