r2441 was meant to ensure we cleanup properly when control-C is used to stop the client, but now that we have sound, it doesn't work anymore and deadlocks in SoundPipeline.stop()
, the call to:
self.pipeline.set_state(gst.STATE_NULL)
never returns, despite the fact that the main loop is still running at that point... Probably because the event is caught in the gstreamer code and is therefore leaving the pipeline in an unusable state.
This only happens on win32 which makes it a real pain to debug. This may well be related to #297
records fatal exceptions so we know how the main loop ended
r3020 fixes this by not doing any sound pipeline cleanup on exit, which isn't ideal but allows us to exit.. r3021 adds more debug and r3022 allows us to force exit if a second control-C is received.
Problem is that this bug also fired when exiting normally, and so the record-fatal-exceptions
patch does not help: the pipeline simply blocks whenever we try to stop it.. so solving #297 may be tough!
Please close this ticket if you cannot reproduce the problem.
Problem is easily reproduced, unfortunately.
Start & connect to session from windows client (via cmd console window).
Right-click on icon and open session-info window.
With session-info window open, use control-C to kill xpra session from client cmd window.
Everything locks up.
Fixed in r3092, please close if confirmed.
With a fedora server including r3092, and a windows client with r3084, I am still having the problem of the session locking up if I try a control-C client side with the session info window open.
Further, even executing an xpra stop (apparently successfully) server-side doesn't eliminate the browser or xterms (or the non-responsive session info window) of the xpra session.
and a windows client with r3084
I don't understand the point of testing a client which does not have the fix included - that is never going to work!
I believe this *was* fixed in r3092 but maybe this broke again in r3095, and maybe fixed again in r3100 (see #297 for details). Please confirm, either by reverting r3095 on top of trunk, or just by running r3092. And if trunk does not work, then we should know what needs to be reverted..
Ok, r3098 client-side, r3105 server-side... fix worked. Don't see any point to any reversions, I'll close the ticket now.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/298