Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 11 days ago

Closed 9 days ago

#758 closed defect (fixed)

Killing barber makes vterm nonresponsive

Reported by: Jakub Jermář Owned by:
Priority: major Milestone: 0.8.0
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description (last modified by Jakub Jermář)

As of commit e131bd05cd3ced3b445c51035c8943d3ead77524, killing the barber app results in rendering the vterm window from which the kill was issued non-responsive.

Bisecting reveals that:

889cdb1c2046af9d31d314fa691773fa2e4f9119 is the first bad commit
commit 889cdb1c2046af9d31d314fa691773fa2e4f9119
Author: Jakub Jermar <jakub@jermar.eu>
Date:   Sun Oct 28 22:36:49 2018 +0100

    Always answer the IPC_M_PHONE_HUNGUP message

Change History (3)

comment:1 Changed 11 days ago by Jakub Jermář

Description: modified (diff)

comment:2 Changed 10 days ago by Jakub Jermář

Applying the following change fixes the issue:

--- a/uspace/srv/hid/compositor/compositor.c
+++ b/uspace/srv/hid/compositor/compositor.c
@@ -1025,9 +1025,9 @@ static void client_connection(ipc_call_t *icall, void *arg)
                        async_get_call(&call);
 
                        if (!IPC_GET_IMETHOD(call)) {
-                               async_answer_0(&call, EOK);
                                comp_window_close(win, &call);
                                window_destroy(win);
+                               async_answer_0(&call, EOK);
                                return;
                        }
 

The bad commit answers call twice and so does this fix. In the case of the bad commit, the call is answered before comp_window_close(), but I don't see why that is significant other than for timing reasons.

comment:3 Changed 9 days ago by Jakub Jermář

Resolution: fixed
Status: newclosed

Fixed in commit 790f3a3a7e4d0de0dc62be56505cd98a8966eaef. As the commit message explains, we must not answer the same call twice or bad things happen, such as answering a completely different call which uses the same handle.

Note: See TracTickets for help on using tickets.