xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

#1420 closed defect (fixed)

Unable to start multiple gnome-terminals

Reported by: Doug Doole Owned by: Doug Doole
Priority: minor Milestone: 2.0
Component: server Version: 1.0.x
Keywords: Cc:

Description

This is on Ubuntu 14.04.5.

I have started my Xpra server with:
xpra start :10 --start-new-commands=yes

I connect locally to the server with:
xpra attach ssh:localhost:10

I then try to start multiple copies of gnome-terminal by repeatedly invoking:
xpra control :10 start gnome-terminal

The first always succeeds, but on a later attempt (typically the second), the Xpra server hangs. When this happens, the title bar and border of the new gnome-terminal appears but the contents are black. Nothing responds in any of the Xpra managed windows. Furthermore, the Xpra icon in the systray is changed to the clipboard icon. (I do not do anything with the clipboard - just run the xpra control commands.)

Running xpra list reports that the session is LIVE. Attempting to stop the session may report success or may give a connection timed out error. Either way, several Xpra processes are left running. It is necessary to manually kill the Xorg-for-Xpra process to clean up Xpra.

In the email thread (same subject as this ticket), Antoine suggested that the problem may be that gnome-terminal is running multiple windows from a single process. It looks like this is the problem as changing the command to:
xpra control :10 start gnome-terminal --disable-factory
causes each instance to be a separate process and avoids the hang.

Attachments (2)

hang.zip (998.9 KB) - added by Doug Doole 4 years ago.
Output of bug report tool taken during the hang
end-of-server-debug-log.txt (7.3 KB) - added by Antoine Martin 4 years ago.
log captured before the server hangs

Download all attachments as: .zip

Change History (10)

Changed 4 years ago by Doug Doole

Attachment: hang.zip added

Output of bug report tool taken during the hang

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Doug Doole

I've tried to reproduce without success, both starting new "gnome-terminal" instances from an existing xterm and using "xpra control."
I never saw big problems. (looks like there is something buggy in gnome-terminal as it spams stdout with warnings - but that's it)

Can you please provide more details so I can reproduce reliably? (DE, etc as per wiki/ReportingBugs)

comment:2 Changed 4 years ago by Doug Doole

Owner: changed from Doug Doole to Antoine Martin

The repro is dead simple. From a single terminal window I run:

xpra start :10 --start-new-commands=yes
xpra attach ssh:localhost:10
xpra control :10 start gnome-terminal
xpra control :10 start gnome-terminal
xpra control :10 start gnome-terminal

The gnome-terminal typically goes bad on the second attempt, but I've had it succeed 3 or 4 times before failing.

Interestingly, I don't see a bunch of errors when I start the gnome-terminals. I just get a report of the PID that was started.

What information would you like beyond what's in the attached .zip from the bug report tool?

comment:3 Changed 4 years ago by Antoine Martin

Milestone: 2.0
Owner: changed from Antoine Martin to Doug Doole
Version: trunk1.0.x

I've started 20 and didn't hit any server hangs.

As for the gnome-terminal errors, you can see those if you start the terminals from an xterm, otherwise they will go to the server log where it floods (16MB after a few minutes).

I suspect that what you're seeing is a clipboard bug, you can confirm this by turning off clipboard synchronization.
I have set the version to 1.0.x as I assume this is what you're testing with, please change it if not.

comment:4 Changed 4 years ago by Antoine Martin

Priority: majorminor

I thought I just saw the problem after leaving the VM alone for a few minutes, but now it is behaving OK.
I suspect the bug is caused by abnormal behaviour in gnome-terminal / GTK.
I still see a stream of:

(gnome-terminal:$PID): Gdk-WARNING: **: gdk-frame-clock: layout continuously requested, giving up after 4 tries.

Which points to this GTK bug: Journal spam: Gdk-WARNING **: gdk-frame-clock: layout continuously requested, giving up after 4 tries.
And this corresponds to storms of damage events with updates to the _NET_WM_OPAQUE_REGION property. (which we do not support, is not exposed as a supported propery and should therefore not be set by client applications..)

If you can still reproduce, can you attach the "-d all" and/or "-d clipboard" server log.
Maybe you can also get a GDB backtrace of what the server process is doing when it hangs? (see wiki/Debugging)

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

Changed 4 years ago by Antoine Martin

Attachment: end-of-server-debug-log.txt added

log captured before the server hangs

comment:5 Changed 4 years ago by Antoine Martin

Owner: changed from Doug Doole to Antoine Martin
Status: newassigned

As per the attachment/ticket/1420/end-of-server-debug-log.txt, the server hangs shortly after:

  • a clipboard request which makes it use the nested loop: Entering nested loop 0x7fd0a0093e10 (level 1)
  • sigchld(17, <frame object at 0x7fd0a0022050>) - maybe gnome-terminal crashed

comment:6 Changed 4 years ago by Antoine Martin

This may have been fixed by r15030, will re-test. Feel free to beat me to it, there are beta 1.0.3 packages for Ubuntu Trusty with this fix included here: http://xpra.org/beta/

comment:7 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to Doug Doole
Status: assignednew

Fix works for me.

Please close this ticket to confirm.

comment:8 Changed 4 years ago by Antoine Martin

Resolution: fixed
Status: newclosed

Fixed and released.

Note: See TracTickets for help on using tickets.