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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 47067 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c
Date: Sat, 13 Mar 2021 19:26:48 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Sat, 13 Mar 2021 17:10:08 +0000
> Cc: Andrea Corallo <akrl <at> sdf.org>, 47067 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.