| 2010-02-08 17:35:52 |
Dave Martin |
bug |
|
|
added bug |
| 2010-02-08 17:35:52 |
Dave Martin |
attachment added |
|
suggested workaround which temporarily blocks each signal while deciding whether to run the handler and resetting the corresponding signal count http://launchpadlibrarian.net/38897794/libnih_Avoid-check-.-reset-race-in-signal_poll.patch |
|
| 2010-02-08 18:05:18 |
Dave Martin |
description |
nih_signal_handler() increments signals_caught[signum] per signal; nih_signal_poll() is responsible for checking and resetting the count.
However, a signal can arrive after nih_signal_poll() decides not to run the handler (because signals_caught[signum] is 0) but before the signals_caught counts are reset at the end of the function. (This is the classic atomicity problem when waiting for signals --- see pselect(2) for background.)
The signal pipe will have been written, which does ensure that nih_main_loop() is guaranteed to wake up again on the next round, but because signals_caught[signum] remains zero for the affected signal, that instance of the signal will be silently ignored when nih_signal_handler() is next called. This can lead to a deadlock if notification of the signal is required for the program to make progress (such as waiting for SIGCHLD to arrive).
The attached patch may serve as a workaround, but it's not been extensively tested.
I know of no real-world deadlock caused by this bug, but I spotted it when investigating a separate deadlock issue. |
nih_signal_handler() increments signals_caught[signum] per signal; nih_signal_poll() is responsible for checking and resetting the count.
However, a signal can arrive after nih_signal_poll() decides not to run the handler (because signals_caught[signum] is 0) but before the signals_caught counts are reset at the end of the function. (This is the classic atomicity problem when waiting for signals --- see pselect(2) for background.)
The signal pipe will have been written, which does ensure that nih_main_loop() is guaranteed to wake up again on the next round, but because signals_caught[signum] remains zero for the affected signal, that instance of the signal will be silently ignored when nih_signal_handler() is next called. This can lead to a deadlock if notification of the signal is required for the program to make progress (such as waiting for SIGCHLD to arrive).
The attached patch may serve as a workaround, but it's not been extensively tested.
I know of no real-world deadlock caused by this bug, but I spotted it when investigating a separate deadlock issue.
This bug was found while investigating the following issue, but is probably not directly related:
* https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/518937 (ply_event_loop_process_pending_events can block, causing mountall to deadlock) |
|
| 2010-02-08 18:09:14 |
Dave Martin |
description |
nih_signal_handler() increments signals_caught[signum] per signal; nih_signal_poll() is responsible for checking and resetting the count.
However, a signal can arrive after nih_signal_poll() decides not to run the handler (because signals_caught[signum] is 0) but before the signals_caught counts are reset at the end of the function. (This is the classic atomicity problem when waiting for signals --- see pselect(2) for background.)
The signal pipe will have been written, which does ensure that nih_main_loop() is guaranteed to wake up again on the next round, but because signals_caught[signum] remains zero for the affected signal, that instance of the signal will be silently ignored when nih_signal_handler() is next called. This can lead to a deadlock if notification of the signal is required for the program to make progress (such as waiting for SIGCHLD to arrive).
The attached patch may serve as a workaround, but it's not been extensively tested.
I know of no real-world deadlock caused by this bug, but I spotted it when investigating a separate deadlock issue.
This bug was found while investigating the following issue, but is probably not directly related:
* https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/518937 (ply_event_loop_process_pending_events can block, causing mountall to deadlock) |
Ubuntu lucid
libnih 1.0.1-1
nih_signal_handler() increments signals_caught[signum] per signal; nih_signal_poll() is responsible for checking and resetting the count.
However, a signal can arrive after nih_signal_poll() decides not to run the handler (because signals_caught[signum] is 0) but before the signals_caught counts are reset at the end of the function. (This is the classic atomicity problem when waiting for signals --- see pselect(2) for background.)
The signal pipe will have been written, which does ensure that nih_main_loop() is guaranteed to wake up again on the next round, but because signals_caught[signum] remains zero for the affected signal, that instance of the signal will be silently ignored when nih_signal_handler() is next called. This can lead to a deadlock if notification of the signal is required for the program to make progress (such as waiting for SIGCHLD to arrive).
The attached patch may serve as a workaround, but it's not been extensively tested.
I know of no real-world deadlock caused by this bug, but I spotted it when investigating a separate deadlock issue.
This bug was found while investigating the following issue, but is probably not directly related:
* https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/518937 (ply_event_loop_process_pending_events can block, causing mountall to deadlock)
|
|
| 2010-02-15 12:04:26 |
Scott James Remnant (Canonical) |
libnih (Ubuntu): status |
New |
Triaged |
|
| 2010-02-15 12:04:27 |
Scott James Remnant (Canonical) |
libnih (Ubuntu): importance |
Undecided |
Medium |
|
| 2010-03-04 17:25:41 |
Scott James Remnant (Canonical) |
bug task added |
|
libnih |
|
| 2010-03-04 17:25:50 |
Scott James Remnant (Canonical) |
libnih: status |
New |
Triaged |
|
| 2010-03-04 17:25:54 |
Scott James Remnant (Canonical) |
libnih: importance |
Undecided |
Medium |
|
| 2010-04-27 17:43:31 |
Scott James Remnant (Canonical) |
libnih (Ubuntu): status |
Triaged |
Invalid |
|
| 2010-09-14 09:59:26 |
Launchpad Janitor |
branch linked |
|
lp:~dave-martin-arm/ubuntu/maverick/libnih/avoid-signal-check-clear-race |
|
