https://bugs.kde.org/show_bug.cgi?id=418840
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #1 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
I think the bug originates from the lazy translation of the scss to skss,
in function static void handle_SCSS_change ( Bool force_update ).
When force_update is false (which is the case when handling a guest
sigaction call), and the old setup is equal to the new setup of the
kernel signal state, then no kernel sigaction is executed.
So, when a signal is blocked+ignored then raised,
the signal is queued by the kernel till it is unblocked (and then
it will be ignored).
In this state, if a blocked signal is re-ignored, the kernel clears it.
But in the same circumstance, valgrind signal handling does not call sigaction:
valgrind does not know that there is a blocked ignored queued signal
in the kernel, it just sees that the signal handling is not changed,
and then it does not call the kernel to tell to re-ignore the signal.
Changing the call of handle_SCSS_change in sys_sigaction to always use
force_update solves the problem, but that means the lazy update of
the signal handling is removed.
It would be possible to detect this case in handle_SCSS_change:
if the current setup is blocked + ignored, then this function
could check if there is a signal pending, and then it should still
call the kernel to clear the blocked signal.
That means one more syscall to get the pending signals in case one or more
signals are blocked + ignored.
--
You are receiving this mail because:
You are watching all bug changes.
