xpra icon
Bug tracker and wiki

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

Opened 6 years ago

Closed 6 years ago

Last modified 8 months ago

#873 closed defect (fixed)

0.15.0 server throwing thread parse exception

Reported by: alas Owned by: alas
Priority: minor Milestone: 0.16
Component: server Version: 0.15.x
Keywords: Cc:


Running an osx client 0.15.0 r9533 against a fedora 20 0.15.0 r9533 server, running a video on firefox to test various things, the server threw the following exception:

2015-05-27 17:58:48,509 sound-source codec: MPEG-1 Layer 3 (MP3)
Exception in thread parse (most likely raised during interpreter shutdown):
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
  File "/usr/lib64/python2.7/threading.py", line 764, in run
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 610, in _read_parse_thread_loop
  File "/usr/lib64/python2.7/site-packages/xpra/net/protocol.py", line 572, in _internal_error
<type 'exceptions.AttributeError'>: 'NoneType' object has no attribute 'error'
2015-05-27 18:05:42,354 using Pulseaudio device 'Monitor of Null Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-05-27 18:05:42,707 sound-source codec: MPEG-1 Layer 3 (MP3)

The client showed a couple of sound-sink errors, meanwhile: sound-sink internal error: write connection TwoFileCOnnection() reset: [Errno 32] Broken pipe ... which I think we've been seeing for a while, but no other interesting information.

Change History (6)

comment:1 Changed 6 years ago by Antoine Martin

Priority: majorminor
Status: newassigned

I have seen this error, and intend to fix it, but it is a low priority: it isn't pretty, but it is harmless.

This happens because when we restart the sound we now restart the process, during the process shutdown things can go wrong (as per the message most likely raised during interpreter shutdown) and we get random errors. We don't care about those since the process is going away anyway.

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

comment:2 Changed 6 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

This is hard to reproduce reliably on win32, managed once with control-C, but not with debugging enabled! (not happening with other plarforms)

@afarr: can you give me the end of the -d all output when this happens?
You may find it easier to trigger by using XPRA_SOUND_FAKE_OVERRUN=2 to make it restart the sound pipeline every 2 seconds.

comment:3 Changed 6 years ago by Antoine Martin

Somewhat related to #896, which tries to ensure we exit all threads cleanly.

comment:4 Changed 6 years ago by alas

Hmm... running 0.15.4 r10055 osx client against a fedora 20 0.15.4 r10133, even with XPRA_SOUND_FAKE_OVERRUN=2 to trigger sound restarts every 2 seconds, I can't repro the traceback.

I am able to get the sound-sink internal error: write connection TwoFileCOnnection() reset: [Errno 32] Broken pipe error, but that sounds to be expected.

I am also now seeing a xpra[28212:d0b] unlockFocus called too many times. Called on <GdkQuartzView: 0x39f6e0>. message, but I'm not sure if it is actually an error.

Let me know if you still want a -d all log clipping.

comment:5 Changed 6 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Closing this for now, we'll re-open if this happens again.
0.16 improves the situation further in 2 ways:

  • we'll do less restarts (work in progress)
  • when we restart, we try harder to exit cleanly (#896)

comment:6 Changed 8 months ago by migration script

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

Note: See TracTickets for help on using tickets.