[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's
From: |
Eli Zaretskii |
Subject: |
bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function |
Date: |
Fri, 19 Oct 2018 11:44:35 +0300 |
> From: Gemini Lasswell <gazally@runbox.com>
> Cc: 33014@debbugs.gnu.org, schwab@linux-m68k.org
> Date: Thu, 18 Oct 2018 17:22:36 -0700
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Anyway, are you saying that stack marking doesn't work in optimized
> > code? We've been using this technique for the last 17 years without
> > problems; why would the fact that we have more than one thread change
> > that? The same arguments you submit are valid for a single-threaded
> > Emacs, right?
>
> Apparently so. I set up a single-threaded situation where I could
> redefine a function while exec_byte_code was running it, and got a
> segfault. I've gained some insights from debugging this version of the
> bug which I will put into a separate email.
If this is the case, then I think we should protect the definition of
a running function from GC, in some way, either by making sure it is
referenced by some stack-based Lisp object, even in heavily optimized
code (e.g., by using 'volatile' qualifiers); or by some other method
that will ensure that definition is marked and not swept.
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, (continued)
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Andreas Schwab, 2018/10/14
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/15
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/15
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/15
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/16
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/16
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/16
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/18
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function,
Eli Zaretskii <=
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/19
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/20
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Andreas Schwab, 2018/10/20
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/20
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Andreas Schwab, 2018/10/20
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/29
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/29
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/19
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/17
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/17