Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 2 weeks ago

Last modified 2 weeks ago

#805 new defect

Debug session not cleaned up if debugger gets killed

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos/unspecified Version: mainline
Keywords: udebug Cc:
Blocker for: Depends on:
See also:

Description

Any number of tasks might have a phone Pn open to a target task T's kbox. At most one of them has an open debugging session (the debugger D). If a Pn is hung up, we call kbox_proc_phone_hungup(), which detects using call→sender == TASK→udebug.debugger that the sending task is D and it cleans up the debug session, unfreezing T.

Now if we kill D in the middle of a debugging session, ipc_cleanup() → phone_cap_cleanup_cb → ipc_phone_hangup which sends hangup_call which has →sender initialized to NULL.

This causes a problem since kbox_proc_phone_hungup() will see call→sender (NULL) != TASK→udebug.debugger and will not clean up the debugging session, leaving the task frozen.

Change History (3)

comment:1 Changed 2 weeks ago by Jiri Svoboda

Any ideas how to approach this? It seems to me maybe sender is NULL on purpose since the sender task is going away. Is the current way of cleaning up the debug session a good design? Or maybe we need something different?

comment:2 Changed 2 weeks ago by Jakub Jermář

Keywords: udebug added

comment:3 Changed 2 weeks ago by Jakub Jermář

This should not be the case of ipc_phone_hangup as there we don't pre-forget the call in _ipc_call, which would prevent _ipc_call_actions_internal from setting the sender. However, it seems to be the case of ipc_answerbox_slam_phones, which pre-forgets the calls.

I guess you are right it has to do with properly disposing of all the calls of an exiting task.

On a related note, I am now working on an ipc2 branch, where I hope to address to cleanup part in a more elegant way.

Note: See TracTickets for help on using tickets.