Xpra: Ticket #298: win32 control-C can deadlock client in gstreamer code

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:


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

Wed, 20 Mar 2013 10:48:31 GMT - Antoine Martin: attachment set

records fatal exceptions so we know how the main loop ended

Wed, 20 Mar 2013 10:52:06 GMT - Antoine Martin: status changed; owner set

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.

Tue, 26 Mar 2013 01:28:08 GMT - alas:

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.

Wed, 17 Apr 2013 11:16:36 GMT - Antoine Martin: owner, status changed

Fixed in r3092, please close if confirmed.

Wed, 17 Apr 2013 22:48:05 GMT - alas: status changed

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.

Thu, 18 Apr 2013 05:56:07 GMT - Antoine Martin: status changed

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..

Thu, 18 Apr 2013 23:15:52 GMT - alas: status changed; resolution set

Ok, r3098 client-side, r3105 server-side... fix worked. Don't see any point to any reversions, I'll close the ticket now.

Sat, 23 Jan 2021 04:50:58 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/298