[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: |
Tue, 16 Oct 2018 22:25:21 +0300 |
> From: Gemini Lasswell <gazally@runbox.com>
> Cc: Andreas Schwab <schwab@linux-m68k.org>, 33014@debbugs.gnu.org
> Date: Tue, 16 Oct 2018 11:46:36 -0700
>
> My knowledge of what gcc does and how the code it generates works is
> superficial, but I don't see why an optimizer would find it necessary to
> save the following values:
>
> - The value of 'fun' in Ffuncall after it is used as an argument for
> funcall_lambda.
>
> - The value of 'fun' in funcall_lambda after it is used to calculate
> the arguments to exec_byte_code.
>
> - The value of 'vector' in exec_byte_code after the calculation of
> vectorp.
There are calling frames as well. For GC to pay attention to a Lisp
object, it is enough to have that object _somewhere_ on the stack.
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?
I think the chance of something like what you describe to happen here
are small, and we shouldn't throw in the towel so quickly. I don't
think we've exhausted all the other possibilities, not yet.
> gdb shows a value for fun in frame 11, but when I try to print
> XIL(0x7fecdacdc468) it complains about it being an invalid lisp object,
> and then the result of "info frame 11" shows some similar values,
> so I'm thinking gdb is confused:
It's quite possible that GDB is not confused, and you've found some
evidence of the problem.
How did you try to print XIL(0x7fecdacdc468)? Maybe we should take a
good look at this object.
> I haven't figured out how to get gdb to print the Lisp backtrace of one
> thread while execution is stopped in a different one.
You can't, AFAIR. The code that helps us produce a Lisp backtrace
doesn't work in that case.
- 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, Eli Zaretskii, 2018/10/13
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/13
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/13
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Gemini Lasswell, 2018/10/14
- bug#33014: 26.1.50; 27.0.50; Fatal error after re-evaluating a thread's function, Eli Zaretskii, 2018/10/14
- 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 <=
- 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, 2018/10/19
- 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