Xpra: Ticket #2026: Do not allow client to die during bug/diagnostic collection

I tried to collect diagnostics for a bug report, however the client decided to kill itself.

It was during a shadow timeout, and the client decided to kill itself immediately.

Kindly hold/block/ignore "the kill signal" while the diagnostics window is open.



Sat, 03 Nov 2018 05:20:36 GMT - Antoine Martin: status changed

Not sure how easy to implement this is going to be. FYI: until that's implemented, you can fire the bug report tool separately from xpra. (see wiki/ReportingBugs)

And as of r20920, simply by running:

xpra bug-report

Sat, 03 Nov 2018 08:13:37 GMT - stdedos:

I was wondering: Does the tool collect "more information" when called from the offending session, or does it collect the same regardless?

It would be nice if you could call it from the server (xpra bug-report :10) or from the client (xpra bug-report ssh://user@ip/10), to collect "everything you need" in memory, and then drop whatever the user didn't want to provide.


Sat, 03 Nov 2018 08:26:20 GMT - Antoine Martin:

Does the tool collect "more information" when called from the offending session, or does it collect the same regardless?

More: it also collects "xpra info".

It would be nice if you could call it from the server (xpra bug-report :10) or from the client (xpra bug-report ssh://user@ip/10), to collect "everything you need" in memory, and then drop whatever the user didn't want to provide.

Please file a separate ticket for that.


Sat, 03 Nov 2018 08:33:55 GMT - Antoine Martin:

New ticket for separate bug reports with xpra info: #2027


Tue, 13 Nov 2018 15:23:46 GMT - Antoine Martin: milestone changed

Difficult:


Wed, 14 Nov 2018 22:31:37 GMT - stdedos:

Could it become easier with a master-slave threading model? (really a shot in the dark)

I was thinking that, GUI/Session is one thread, Bugs are another (if called). GUI going down would mean nothing. Session's memory can be shared with master thread (or allocated at master, shared at GUI), and bug thread could ask master to dump whatever it is to dump.

If the pool of threads is empty, then master can destroy whatever and kill itself.


Thu, 15 Nov 2018 02:36:19 GMT - Antoine Martin:

Could it become easier with a master-slave threading model? (really a shot in the dark)

With GTK, there is only one thread that can access the UI, the master thread. That's the one that is terminated by events such as "connection lost" messages.


Sat, 23 Jan 2021 05:40:10 GMT - migration script:

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