#1919 closed defect (needinfo)
OSX <-> Ubuntu `gnome-panel --replace` causes logout and crash
Reported by: | Viral | Owned by: | Viral |
---|---|---|---|
Priority: | major | Milestone: | 2.4 |
Component: | client | Version: | 2.3.x |
Keywords: | osx gnome ubuntu client crash | Cc: |
Description (last modified by )
I'm really amazed by this one, but after I've connected to my local server via the xpra client, if I restart gnome-panel --replace
after it's already running, my mac explodes, as in a logout is triggered, all apps open crash, and xpra is closed. I had to reboot afterwords.
I've reproduce this twice now.
Attachments (3)
Change History (12)
Changed 4 years ago by
Attachment: | 1919-bug-report.txt added |
---|
comment:1 Changed 4 years ago by
Description: | modified (diff) |
---|---|
Milestone: | → 2.4 |
Owner: | changed from Antoine Martin to Viral |
What is the server command?
Is gnome-panel forwarded individually, or is it part of a desktop session?
Does the crash still occur if you turn off opengl in the client?
xpra should never be able to crash your OS, the OS is meant to shield you from that.. a bug in your opengl drivers is the most likely explanation for the crash.
You may want to try some of the beta python3 builds you can find here: https://xpra.org/beta/macos
And also try using the native opengl bindings with xpra attach XXXX --opengl=native
Assuming that this is reproducible, we should be able to figure out the cause by running the client like this:
xpra attach XXXXX -d all >& log
By the time the process crashes, the log should contain the last few instructions before the crash, which should give us a clue.
comment:2 Changed 4 years ago by
What is the server command?
I've had it happen via gnome-panel
and gnome-session
, now 3 times.
Is gnome-panel forwarded individually, or is it part of a desktop session?
I think I've seen it happen via xpra start
and xpra start-desktop
Does the crash still occur if you turn off opengl in the client?
Not sure, will attempt to investigate.
xpra should never be able to crash your OS, the OS is meant to shield you from that.. a bug in your opengl drivers is the most likely explanation for the crash.
Absolutely, which is why I'm rather dumb founded by it. And it's not so much crashing my OS as forcing a logout and killing various apps.
You may want to try some of the beta python3 builds you can find here:
https://xpra.org/beta/MacOS
And also try using the native opengl bindings with xpra attach XXXX --opengl=native
Will attempt
Thanks
comment:3 Changed 4 years ago by
Still attempting to reproduce, I did however get a sig fault from just restarting gnome-panel/gnome-session/nautilus
Probably unrelated, could be related to my mac's uptime, but it was pretty low for me <4 days.
I'll try to collect more information.
Switching to betas for now, thanks
comment:4 Changed 4 years ago by
OFF TOPIC
Xpra-Python3-x86_64-2.4-r19414.dmg crashes when clicking "Load" behaviour is 100% reproducible, attempting earlier beta
comment:5 Changed 4 years ago by
Can reproduce "Load" crash on Xpra-Python3-x86_64-2.4-r19815.dmg
as well.
Regards
comment:6 Changed 4 years ago by
The crash seems to be in the systray code, try --tray=no
and / or --system-tray=no
Changed 4 years ago by
Attachment: | 1919-bug-report.2.txt added |
---|
moving bug report data to an attachment
Changed 4 years ago by
Attachment: | load-bug-trace.txt added |
---|
moving bug report data to an attachment
comment:7 Changed 4 years ago by
Xpra-Python3 (..) crashes when clicking "Load" behaviour is 100% reproducible
Confirmed, moving this to #1938
As for the rest, I still cannot reproduce here.
comment:8 Changed 4 years ago by
Resolution: | → needinfo |
---|---|
Status: | new → closed |
Feel free to re-open if you have more data or a reproducible test case.
In all likelihood, this is not an xpra bug but an graphics driver bug.
comment:9 Changed 17 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1919
moving bug report data to an attachment