xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 9 years ago

Closed 8 years ago

Last modified 8 months ago

#298 closed defect (fixed)

win32 control-C can deadlock client in gstreamer code

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 0.9
Component: client Version: trunk
Keywords: win32 Cc:

Description

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

Attachments (1)

record-fatal-exceptions.patch (2.5 KB) - added by Antoine Martin 9 years ago.
records fatal exceptions so we know how the main loop ended

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by Antoine Martin

records fatal exceptions so we know how the main loop ended

comment:1 Changed 9 years ago by Antoine Martin

Owner: set to aradtech
Status: newassigned

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.

Last edited 9 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by Antoine Martin

Owner: changed from aradtech to alas
Status: assignednew

Fixed in r3092, please close if confirmed.

comment:4 Changed 8 years ago by alas

Status: newassigned

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.

comment:5 Changed 8 years ago by Antoine Martin

Status: assignednew

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

Last edited 8 years ago by Antoine Martin (previous) (diff)

comment:6 Changed 8 years ago by alas

Resolution: fixed
Status: newclosed

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

comment:7 Changed 8 months ago by migration script

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

Note: See TracTickets for help on using tickets.