bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

These errors are transient. I can try again, and it succeeds.

On Wed, May 22, 2024 at 1:21 PM Simen Endsjø <simendsjo@gmail.com> wrote:
>
> 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ø <simendsjo@gmail.com> 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 <ssbssa@yahoo.de> wrote:
> > >
> > >  Am Mittwoch, 22. Mai 2024 um 10:41:28 MESZ hat Simen Endsjø 
> > > <simendsjo@gmail.com> 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