When quitting xine by parameter -pq after playing for example a very short
H.264 file with just a single frame, xine did crash at different locations.
Fixing one location revealed another and so on. Hopefully, all places have
been addressed now.
src/xitk/oxine/oxine.c | 161 ++++++++++++++++++++++++++++++------------
src/xitk/xine-toolkit/xitk.c | 69 ++++++++++++++++-
src/xitk/event.c | 10 ++-
src/xitk/actions.c | 4 +-
src/xitk/actions.c | 3 -
src/xitk/main.c | 3 +
6 files changed, 192 insertions(+), 58 deletions(-)
gui_deinit() must wait for a pending event handler to return before setting
reject_events. Otherwise it will continue to shutdown xine and destroy
windows on which the event handler is currently working on.
To allow gui_deinit() to be called from the event handler, the mutex needs
to be changed to a recursive one. Otherwise a deadlock happens.
src/xitk/event.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
oxine_exit() must not destroy oxine_instance while it is in use for
example by a callback function.
To track usage, oxine_instance_get() and oxine_instance_unget() have
been introduced and put into each function which was previously using
src/xitk/oxine/oxine.c | 161 +++++++++++++++++++++++++++++++++++-------------
1 files changed, 116 insertions(+), 45 deletions(-)
In several places it was assumed that failure to lock an event handler
mutex means that it was locked already by the same thread. But that is
not always true. Storing the thread which currently owns the mutex helps
to detect and handle this scenario properly.
It is not safe to walk the event handler queue without protecting the
queue from being modified. The concerned mutex must be changed to a
recursive one or the toggle fullscreen event will deadlock.
src/xitk/xine-toolkit/xitk.c | 69 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 62 insertions(+), 7 deletions(-)