xpra icon
Bug tracker and wiki

Opened 7 months ago

Last modified 6 months ago

#2026 assigned enhancement

Do not allow client to die during bug/diagnostic collection

Reported by: stdedos Owned by: Antoine Martin
Priority: major Milestone: future
Component: client Version: 2.4.x
Keywords: Cc:

Description

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.

Change History (7)

comment:1 Changed 7 months ago by Antoine Martin

Status: newassigned

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

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

comment:3 Changed 7 months ago by 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.

comment:4 Changed 7 months ago by Antoine Martin

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

comment:5 Changed 6 months ago by Antoine Martin

Milestone: 2.5future

Difficult:

  • the launcher gui overrides some of the exit methods
  • so does the disconnect notification code: r20984
  • keeping the client running after the server requested disconnection will trigger all sorts of problems (pings won't be received, we'll paint spinners over the windows, etc)

comment:6 Changed 6 months ago by 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.

comment:7 Changed 6 months ago by 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.

Note: See TracTickets for help on using tickets.