Subject: bug#70914: 29.3; Crashes often on Windows

From: Simen Endsjø <[email-masked]>
Date: Wed, 22 May 2024 13:21:57 +0200

Tried building native-compilation with this patch, but that still fails:

make[3]: Entering directory
'/d/tmp/emacs-bug-70914/emacs-empty-path-bug-workaround-regular-build/lisp'
  ELC+ELN  international/titdic-cnv.elc
  ELC+ELN  ../lisp/abbrev.elc
  ELC+ELN  ../lisp/bindings.elc
  ELC+ELN  ../lisp/buff-menu.elc
  ELC+ELN  ../lisp/button.elc
  ELC+ELN  ../lisp/composite.elc
  ELC+ELN  ../lisp/case-table.elc
  ELC+ELN  ../lisp/cus-face.elc
  ELC+ELN  ../lisp/cus-start.elc
  ELC+ELN  ../lisp/custom.elc
  ELC+ELN  ../lisp/disp-table.elc
  ELC+ELN  ../lisp/dnd.elc

Backtrace:
00007ff7a5f20f4e
00007ff7a5dea381
00007ff7a5e0b241
00007ff7a5f8666a
00007fffedd7b240
00007fffef7d49f7
00007fffef74e45e
00007fffef7d39e6
00007ff7a5e874b8
00007ff7a5e8747f
00007ff7a5e87563
00007ff7a5e8747f
00007ff7a5e87813
00007ff7a5e8f866
00007ff7a5e91a1b
00007fff6f15cf3d
00007ff7a5e8002a
00007ff7a5e802d0
00007fff6f1652b8
00007ff7a5e8002a
00007ff7a5e802d0
00007fff554212d5
00007ff7a5eca388
00007ff7a5e8002a
00007ff7a5e88294
00007ff7a5e8002a
00007fff55422f6e
00007ff7a5e8002a
00007fff55423334
00007ff7a5e8002a
00007ff7a5e88294
00007fff554235d5
00007ff7a5e8002a
00007fff5542ce33
00007ff7a5e8002a
00007fff5542e2d7
00007ff7a5e8002a
00007fff5542e6a4
00007ff7a5e8002a
00007ff7a5e7ea3b
00007ff7a5e7f4f5
00007ff7a5e7eb4e
00007ff7a5e7f585
00007ff7a5e7eb4e
00007ff7a5e825b5
00007ff7a5e7eb4e
00007ff7a5e7f3a5
00007ff7a5e7eb4e
00007ff7a5e825b5
00007ff7a5e7eb4e
00007ff7a5e7ee25
00007ff7a5e7eb4e
00007ff7a5e7eb4e
00007ff7a5e820cd
00007ff7a5e7eb4e
00007ff7a5e820cd
00007ff7a5e7eb4e
00007ff7a5e7fa75
00007ff7a5e817c6
00007ff7a5e7e543
00007ff7a5e820cd
00007ff7a5e7eb4e
...

On Wed, May 22, 2024 at 1:09 PM Simen Endsjø <[email-masked]> wrote:
>
> > I tend to avoid inferior function calls as much as possible, even more
> > so in optimized code, exactly for this kind of problem.
> >
> > Instead I use something like:
> >
> > (gdb) condition 1 name && $_streq(name,"//")
> >
> > It needs the python build of gdb, in case you used the non-python one.
>
> This resulted in the exact same problem.
>
>
>  > And did you try my suggested quick fix, just to see if it fixes the crash?
>
>  Thanks! That workaround fixed this crashbug at least!
>
>  Unsure about the way forward:
>  - Add a new issue to fix this bug? Is it a correct fix or should the value
>    never be able to exist at all?
>  - Find out where value originates from. I see it is extracted from a lisp
>    object.
>  - Why is the stack garbled?
>  - Why does gdc crash with 0202 when using a conditional format?
>
> On Wed, May 22, 2024 at 10:50 AM Hannes Domani <[email-masked]> wrote:
> >
> >  Am Mittwoch, 22. Mai 2024 um 10:41:28 MESZ hat Simen Endsjø <[email-masked]> Folgendes geschrieben:
> >
> > > > 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. 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.
> >
> > I tend to avoid inferior function calls as much as possible, even more
> > so in optimized code, exactly for this kind of problem.
> >
> > Instead I use something like:
> >
> > (gdb) condition 1 name && $_streq(name,"//")
> >
> > It needs the python build of gdb, in case you used the non-python one.
> >
> >
> > > > And did you try my suggested quick fix, just to see if it fixes the crash?
> > >
> > > 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.
> >
> > From what I saw while I had the dprintf command from earlier active, emacs
> > calls this function even if you maybe don't expect it, so I wouldn't rule
> > it out.
> >
> >
> > Hannes