bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

[Eli Zaretskii <eliz@gnu.org>]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 13 Mar 2021 17:10:08 +0000
> Cc: Andrea Corallo <akrl@sdf.org>, 47067@debbugs.gnu.org
> 
> > > It's a long function, that might not have been enough.
> >
> > But since I found those two, everything before that is irrelevant,
> > right?
> 
> Assuming all code paths hit these insns, yes.

Then tell me how far back to go.

Or, better yet, perhaps there's a way of displaying that code in C?

> Since mingw (at least the version I could find) declares setjmp with
> the "returns_twice" attribute, I'm assuming their implementation is
> not such that you can call it through a function pointer.

I think you are looking at a 64-bit MinGW64, but I'm out of my depth
here anyway.  If you want to pursue this further, the implementation I
use is in MSVCRT.DLL.

> > > > Note how arguments to Funcall's are the same, whereas arguments to
> > > > funcall_lambda's aren't.  Even the garbage in the 2 arguments to
> > > > wrong_type_argument are identical.
> > >
> > > Which non-stack addresses are invariant in that backtrace?
> >
> > Not sure how stack-based vs non-stack based is important here.
> 
> If non-stack addresses vary between runs and stack addresses don't, I
> don't see any evidence we're looking at corruption here.

Why would non-stack base addresses change?  There's no ASLR here.

Anyway, if that doesn't help, just forget it.