Solve deadlock in notification bar

calcurse deadlocks when

1) an upcoming appointment is on display in the notification bar,
2) an external command (like help) is started,
3) the time for the upcoming appointment arrives, and
4) the external command is exited.

The notification bar thread is stopped while the external command is
running. Upon exit from the external command, the n-bar thread is
restarted and calcurse locks.

The cause is the way in which the main notification bar thread is
stopped:

static pthread_t notify_t_main;
void notify_stop_main_thread(void)
{
	if (notify_t_main) {
		pthread_cancel(notify_t_main);
		pthread_join(notify_t_main, NULL);
	}
}

Objects of type pthread_t are opaque and should not be accessed
directly.  Initially notify_t_main is an uninitialised static variable
(0), but later it has a value, which may or may not be the thread id of
the notification main thread.

Note that the thread id after exit of a thread may become the thread id
of a new thread. Thus the variable set when the thread is created, is
invalid after exit of the thread.

Specifically, the first time notify_stop_main_thread() is called (by
notify_start_main_thread() before the thread is created) is harmless
(because notify_t_main is 0). Calling notify_stop_main_thread() later
may be either

OK
    because the main thread is running, or
harmless
    because no thread with id notify_t_main is running: the two
    functions will fail with return value ESRCH (no such process), or
fatal
    because an unrelated thread with this thread id is running: it will
    be cancelled, and the join may or may not succeed depending on
    whether the thread is joinable or detached.

The "unrelated thread" could be the next-appointment thread,
notify_thread_app, launched by notify_check_next_app().

Always calling notify_stop_main_thread() before starting the main thread
becomes fatal when notify_check_next_app() is called shortly before
notify_start_main_thread(). This is the case in the scenario described.
The next-app-thread is then running when notify_stop_main_thread() is
called, and apparently it has the thread id of the old main thread
(confirmed by logging the return values from pthread_cancel() and
pthread_join(); the first succeeds while the second fails with EINVALID
which means that the thread is not joinable). The next-app-thread will
therefore exit without unlocking mutexes.

Ensure that notify_t_main, in case the notify main thread is not
running, has a value that it will never have when it is running. A
possibility is the thread id of the main() calcurse process (returned by
pthread_self()).

Check for this condition in notify_stop_main_thread() and set
notify_t_main when the thread is stopped.

Similar changes have been introduced for the periodic save thread and
the calendar date thread.

Signed-off-by: Lars Henriksen <LarsHenriksen@get2net.dk>
Signed-off-by: Lukas Fleischer <lfleischer@calcurse.org>

0 files changed, 0 insertions, 0 deletions