bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

> 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