bug#70914: 29.3; Crashes often on Windows

["Simen Endsjø" <simendsjo@gmail.com>]

Doesn't look very fruitful

    (gdb) bt
    #0  0x0000000000000000 in ?? ()
    #1  0x0000000000000000 in ?? ()
    (gdb) p/x *(uintptr_t *)($sp + 8)
    $2 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 16)
    $3 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 24)
    $4 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 32)
    $5 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 40)
    $6 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 48)
    $7 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 56)
    $8 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + 64)
    $9 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 9))
    $10 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 10))
    $11 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 11))
    $12 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 12))
    $13 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 13))
    $14 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 14))
    $15 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 15))
    $16 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 16))
    $17 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 17))
    $18 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 18))
    $19 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 19))
    $20 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 20))
    $21 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 21))
    $22 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 22))
    $23 = 0x0
    (gdb) p/x *(uintptr_t *)($sp + (8 * 23))
    $24 = 0x0

On Mon, May 20, 2024 at 8:20 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Simen Endsjø <simendsjo@gmail.com>
> > Date: Mon, 20 May 2024 19:54:38 +0200
> > Cc: 70914@debbugs.gnu.org, corwin@bru.st
> >
> > > Please try this with a healthy Emacs process before you do it after
> > > the crash, to make sure this procedure works.  Here's my attempt to
> > > validate this technique:
> >
> > Looks like I needed a binary with debugging symbols, so I used my previous
> > build. It's as good as any other. But looks like there are two stack frames with
> > zero pointers, so the technique doesn't work?
> >
> >     Thread 1 received signal SIGSEGV, Segmentation fault.
> >     0x0000000000000000 in ?? ()
> >     (gdb) thread 1
> >     [Switching to thread 1 (Thread 19884.0x7bf8)]
> >     #0  0x0000000000000000 in ?? ()
> >     (gdb) p/x *(uintptr_t *)$sp
> >     $1 = 0x0
> >     (gdb) list *$
> >     (gdb) bt
> >     #0  0x0000000000000000 in ?? ()
> >     #1  0x0000000000000000 in ?? ()
> >     (gdb)
>
> There are two zeros on the stack.  Bummer.
>
> What does this produce:
>
>   (gdb) p/x *(uintptr_t *)($sp + 8)
>
> If the value is non-zero, try listing it:
>
>   (gdb) list *$
>
> If the above yields zero, try $sp+16, $sp+24, etc., until you get a
> non-zero value.