bug#70914: 29.3; Crashes often on Windows

[Hannes Domani]

 Am Dienstag, 21. Mai 2024 um 20:31:37 MESZ hat Eli Zaretskii <eliz@gnu.org> 
Folgendes geschrieben:

> > From: Simen Endsjø <simendsjo@gmail.com>
> > Date: Tue, 21 May 2024 19:39:13 +0200
> > Cc: 70914@debbugs.gnu.org, corwin@bru.st
> >
> > > Could you please show the last few
> > > DLLs loaded by thread 1?
> >
> > Heres only Thread 1:
>
> Thanks.
>
> I'm sorry, I'm out of ideas.  Maybe someone else will have
> suggestions.  Or maybe we are lucky and someone else reports similar
> crashes with additional info.  I can only say that Emacs works
> flawlessly for me on Windows 11 (but it's Emacs I build myself with
> optional libraries most of which I also built myself).
>
> I asked on the GDB list for suggestions how to debug such crashes,
> maybe someone there will come up with a useful suggestion.

I'm saw it on the GDB list, and tried to reproduce a similar backtrace
with just zeros.

I came up with this:
```
// compile with -g -O1 -foptimize-sibling-calls

#include <string.h>

int other_function(int x)
{
  return x + 3;
}

int some_function(int size)
{
  int (*function_ptr)(int) = &other_function;
  memset(&function_ptr, 0, size);
  return function_ptr(5);
}

int main()
{
  int y = some_function(100);
  return y;
}
```

So when i intentionally break the stack, and make it 'jump' there with
a sibling call, I get this result in GDB:
```
C:\src\test>gcc -o no-bt.exe no-bt.c -g -O1 -foptimize-sibling-calls

C:\src\test>gdb -q no-bt.exe
Reading symbols from no-bt.exe...
(gdb) r
Starting program: C:\src\test\no-bt.exe
[New Thread 7632.0x4328]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb)
```

Usually I would say it's not possible to find out anything from here,
but if you have a recent Win10, and a recent enough Intel CPU (which I
think you do from what I saw in this ticket), then you could try
out my GDB build [1] which includes some extra stuff that I haven't
upstreamed (yet).

In particular I ported 'record btrace pt' [2] to Windows.

With the same example I can do this:
```
C:\src\test>gdb -q no-bt.exe
Reading symbols from no-bt.exe...
(gdb) start
Temporary breakpoint 1 at 0x7ff7a2d2163a: file no-bt.c, line 18.
Starting program: C:\src\test\no-bt.exe
[New Thread 3924.0x3afc]

Thread 1 hit Temporary breakpoint 1, main () at no-bt.c:18
18      {
(gdb) record btrace pt
(gdb) c
Continuing.

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb) reverse-stepi
0x00007ff7a2d21637 in some_function (size=<optimized out>) at no-bt.c:14
14        return function_ptr(5);
(gdb) bt
#0  0x00007ff7a2d21637 in some_function (size=<optimized out>) at no-bt.c:14
#1  0x00007ff7a2d2164e in main () at no-bt.c:19
Backtrace stopped: not enough registers or memory available to unwind further
(gdb)
```

So with the recording it's possible to go back one instruction from the
crash, and it shows me the location it jumped from.

Note that this is not a 'full' recording, so the amount of steps
to go back is limited (though the buffer-size for that can be changed
with e.g.  'set record btrace pt buffer-size 65536'), and you
can NOT inspect variables while replaying the execution.

But for this kind of problem it's hopefully enough to see what the
previous instructions were.


Hannes


[1] https://github.com/ssbssa/gdb/releases
[2] 
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Process-Record-and-Replay.html