| 2008-12-17 19:23:25 |
Nikodemus Siivola |
bug |
|
|
added bug |
| 2008-12-19 19:47:43 |
Nikodemus Siivola |
description |
On those architectures where :C-STACK-IS-CONTROL-STACK is in
*FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
so we cannot handle the signal directly (as in interrupt_handle_now())
in the case when the signal comes from some external agent (the user
using kill(1), or a fault in some foreign code, for instance). As
of sbcl-0.8.20.20, this is fixed by calling
arrange_return_to_lisp_function() to a new error-signalling
function, but as a result the error reporting is poor: we cannot
even tell the user at which address the fault occurred. We should
arrange such that arguments can be passed to the function called from
arrange_return_to_lisp_function(), but this looked hard to do in
general without suffering from memory leaks. |
On those architectures where :C-STACK-IS-CONTROL-STACK is in
*FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
so we cannot handle the signal directly (as in interrupt_handle_now())
in the case when the signal comes from some external agent (the user
using kill(1), or a fault in some foreign code, for instance).
Tthis is fixed by calling arrange_return_to_lisp_function() to a new error-signalling
function, but as a result the error reporting is brittle: the fault address is passed to
lisp code in a global variable, which is decidedly not threadsafe.
lt occurred. We should arrange such that arguments can be passed to the function
called from arrange_return_to_lisp_function(), but this looked hard to do in general
without suffering from memory leaks.
There are other use-cases of passing arguments via a_r_t_l_f as well.
|
|
| 2008-12-19 19:47:43 |
Nikodemus Siivola |
title |
Memory fault error reporting |
memory fault error reporting |
|
| 2008-12-19 19:48:21 |
Nikodemus Siivola |
description |
On those architectures where :C-STACK-IS-CONTROL-STACK is in
*FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
so we cannot handle the signal directly (as in interrupt_handle_now())
in the case when the signal comes from some external agent (the user
using kill(1), or a fault in some foreign code, for instance).
Tthis is fixed by calling arrange_return_to_lisp_function() to a new error-signalling
function, but as a result the error reporting is brittle: the fault address is passed to
lisp code in a global variable, which is decidedly not threadsafe.
lt occurred. We should arrange such that arguments can be passed to the function
called from arrange_return_to_lisp_function(), but this looked hard to do in general
without suffering from memory leaks.
There are other use-cases of passing arguments via a_r_t_l_f as well.
|
On those architectures where :C-STACK-IS-CONTROL-STACK is in
*FEATURES*, we handle SIG_MEMORY_FAULT (SEGV or BUS) on an altstack,
so we cannot handle the signal directly (as in interrupt_handle_now())
in the case when the signal comes from some external agent (the user
using kill(1), or a fault in some foreign code, for instance).
Tthis is fixed by calling arrange_return_to_lisp_function() to a new error-signalling
function, but as a result the error reporting is brittle: the fault address is passed to
lisp code in a global variable, which is decidedly not threadsafe.
lt occurred. We should arrange such that arguments can be passed to the function
called from arrange_return_to_lisp_function(), but this looked hard to do in general
without suffering from memory leaks.
There are probably other use-cases of passing arguments via a_r_t_l_f as well.
|
|
| 2008-12-19 19:48:40 |
Nikodemus Siivola |
sbcl: status |
New |
Confirmed |
|
| 2008-12-19 19:48:40 |
Nikodemus Siivola |
sbcl: importance |
Undecided |
Low |
|
| 2008-12-19 19:48:40 |
Nikodemus Siivola |
sbcl: statusexplanation |
|
|
|
| 2017-12-17 04:30:25 |
Alastair Bridgewater |
sbcl: status |
Confirmed |
Fix Committed |
|
| 2017-12-29 10:45:34 |
Christophe Rhodes |
sbcl: status |
Fix Committed |
Fix Released |
|
