bug#70914: 29.3; Crashes often on Windows

[Eli Zaretskii <eliz@gnu.org>]

> From: Simen Endsjø <simendsjo@gmail.com>
> Date: Wed, 22 May 2024 10:41:16 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Corwin Brust <corwin@bru.st>, 
> 	"70914@debbugs.gnu.org" <70914@debbugs.gnu.org>
> 
> > That doesn't sound good.
> > Maybe you could show me how you set the conditional breakpoint, and
> > how it crashed, so I can take a look at this on gdb side.
> 
> I do a C-c in gdb to add a breakpoint, and when continuing, the process exists
> with code 0202.

0202 is 130 decimal.  I don't ATM see any calls to exit with such an
exit code in Emacs, but you can find out who causes us to exit with
this status like this:

  gdb ./emacs.exe
  ...
  (gdb) break exit
  (gdb) break _exit
  (gdb) break abort
  (gdb) run

Then do whatever you need to cause these exits, and produce a
backtrace when one of the 3 breakpoints above breaks.

> If I add the conditional breakpoint at start, this doesn't
> happen though, but it seems like it gets stuck without progressing further.
> `print name != NULL` and `print (int)strcmp(name, "//") == 0` doesn't trigger an
> error.

Conditional breakpoints in code that gets called a lot is not a very
good idea, as it will slow down Emacs significantly, even if the
condition is correct (which it isn't in your case).  That's why I
suggest the emacs_abort method, see my other message.

> No, not yet. I'm afraid this isn't the root cause of my problems though. I
> experienced a crash yesterday running `evil-fill-and-move` (format paragraph),
> which probably shouldn't use any disk operations like this.

You cannot know that, not for sure.  That function is called all over
the place in Emacs.  But I still wonder where did that "//" file name
come from, it shouldn't happen.