Recent update results in user input to windows being blocked

[unman]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

All

---

Expected behavior:

Should be able to select any window and work in it.

Actual behavior:

A target window seems completely unresponsive.
Interestingly, opening another window for the same qube somehow allows input to appear in window.
For example, typing in xterm produces no output: but opening another xterm for the same qube results in typed commands appearing in first window and being processed.

Steps to reproduce the behavior:

Intermittent, but can be triggered by resizing window, or working in another qube and then tabbing back to target window. Experiment suggests that the commands are buffered and sent to the target window following trigger.

General notes:

Updated all templates on 2017-04-23, and noticed effect immediately. The effect is intermittent but frequent.
Although I focus on keyboard input, I have seen the same effect with mouse selection also.

---

Related issues:

[marmarek]

What template(s)? I guess it may be side effect of QubesOS/qubes-gui-agent-linux@53ac536 - that QubesBlockHandler isn't called soon enough. @HW42 any idea?

[marmarek]

What template(s)? I guess it may be side effect of QubesOS/qubes-gui-agent-linux@53ac536 - that QubesBlockHandler isn't called soon enough. @HW42 any idea?

[unman]

I see the effect with Debian templates: that's what I use. I did try a Fedora-24 and saw the same issue.

[unman]

I see the effect with Debian templates: that's what I use. I did try a Fedora-24 and saw the same issue.

[marmarek]

Ok, I can reproduce the issue. It does happen on Fedora-24, but does not on Fedora-25. Steps to reproduce:

1. Have VM based on fedora-24 template, with qubes-gui-vm-3.2.16-1.fc24.x86_64 installed.
2. Open xterm there.
3. Maximize/unmaximize it few times, until window content freezes

Observations: gui-agent indeed waits on read() on a socket to X server, so it does look like X server does not respond to it. X server is just waiting on select(). Anything that talks to X server (launching another application, or even xhost) cures the symptoms.

@unman does it happen on Debian 8 or 9, or both?
Maybe we should make gui-agent code introduced with QubesOS/qubes-gui-agent-linux@53ac536 conditional and use it only on new X server, but use the old version on older X server?

[marmarek]

Ok, I can reproduce the issue. It does happen on Fedora-24, but does not on Fedora-25. Steps to reproduce:

1. Have VM based on fedora-24 template, with qubes-gui-vm-3.2.16-1.fc24.x86_64 installed.
2. Open xterm there.
3. Maximize/unmaximize it few times, until window content freezes

Observations: gui-agent indeed waits on read() on a socket to X server, so it does look like X server does not respond to it. X server is just waiting on select(). Anything that talks to X server (launching another application, or even xhost) cures the symptoms.

@unman does it happen on Debian 8 or 9, or both?
Maybe we should make gui-agent code introduced with QubesOS/qubes-gui-agent-linux@53ac536 conditional and use it only on new X server, but use the old version on older X server?

[rtiangha]

Just jumping in: It definitely happens on Debian 8 as that's the template I mostly use in my day-to-day operations. Haven't tried Debian 9 myself as I only use that as a NetVM.

[rtiangha]

Just jumping in: It definitely happens on Debian 8 as that's the template I mostly use in my day-to-day operations. Haven't tried Debian 9 myself as I only use that as a NetVM.

[unman]

@marmarek Apparently not on Debian-9. At least I cant trigger it easily, as I can with 8.

[unman]

@marmarek Apparently not on Debian-9. At least I cant trigger it easily, as I can with 8.

[HW42]

@marmarek:

Maybe we should make gui-agent code introduced with QubesOS/qubes-gui-agent-linux@53ac536 conditional and use it only on new X server, but use the old version on older X server?

QubesOS/qubes-gui-agent-linux@203c38b does effectively this.

See QubesOS/qubes-gui-agent-linux#14

[HW42]

@marmarek:

Maybe we should make gui-agent code introduced with QubesOS/qubes-gui-agent-linux@53ac536 conditional and use it only on new X server, but use the old version on older X server?

QubesOS/qubes-gui-agent-linux@203c38b does effectively this.

See QubesOS/qubes-gui-agent-linux#14

[marmarek]

Merged and uploaded: QubesOS/updates-status#43
Thanks @HW42

[marmarek]

Merged and uploaded: QubesOS/updates-status#43
Thanks @HW42

[tonsimple]

Jumping in:

Had this recently when launching lots of template VMs to update them (I first wait for all of them to start and display the updater window, then go one-by-one and start the update by typing in "y", but some just failed to "get" the y input, which was... annoying), seems especially perniciously persistent in Debian but I also have this with fedora-24-minimal.

[tonsimple]

Jumping in:

Had this recently when launching lots of template VMs to update them (I first wait for all of them to start and display the updater window, then go one-by-one and start the update by typing in "y", but some just failed to "get" the y input, which was... annoying), seems especially perniciously persistent in Debian but I also have this with fedora-24-minimal.

[andrewdavidwong]

Duplicate of #2765.

[andrewdavidwong]

Duplicate of #2765.

[unman]

@andrewdavidwong This is not a duplicate of #2765, because you say there that that was caused by qubes-libvchan-xen upgrade and this is definitely caused by the gui-agent-linux upgrade. (I've checked from a vanilla Debian-8 and the issue appears after upgrading only gui-agent-linux package.)

[unman]

@andrewdavidwong This is not a duplicate of #2765, because you say there that that was caused by qubes-libvchan-xen upgrade and this is definitely caused by the gui-agent-linux upgrade. (I've checked from a vanilla Debian-8 and the issue appears after upgrading only gui-agent-linux package.)

[andrewdavidwong]

This is not a duplicate of #2765, because you say there that that was caused by qubes-libvchan-xen upgrade and this is definitely caused by the gui-agent-linux upgrade. (I've checked from a vanilla Debian-8 and the issue appears after upgrading only gui-agent-linux package.)

No, I said:

The problem seems to have started right after updating qubes-libvchan-xen to 3.2.1, but this is merely an observed correlation.

[andrewdavidwong]

This is not a duplicate of #2765, because you say there that that was caused by qubes-libvchan-xen upgrade and this is definitely caused by the gui-agent-linux upgrade. (I've checked from a vanilla Debian-8 and the issue appears after upgrading only gui-agent-linux package.)

No, I said:

The problem seems to have started right after updating qubes-libvchan-xen to 3.2.1, but this is merely an observed correlation.

[unman]

You also said -

Ok, but I observed the problem before the recent gui-agent update.

and reported that

Chromium browser seems to be the only app/window that freezes

So it cant be a duplicate can it?
I think your original issue report in #2765 related to chromium use, and identified an issue which shouldn't be conflated with this one. That isn't to say that the fix provided by HW42 might not fix both.

[unman]

You also said -

Ok, but I observed the problem before the recent gui-agent update.

and reported that

Chromium browser seems to be the only app/window that freezes

So it cant be a duplicate can it?
I think your original issue report in #2765 related to chromium use, and identified an issue which shouldn't be conflated with this one. That isn't to say that the fix provided by HW42 might not fix both.

[andrewdavidwong]

You also said -

Ok, but I observed the problem before the recent gui-agent update.

and reported that

Chromium browser seems to be the only app/window that freezes

So it cant be a duplicate can it?

Sure it can. What I experienced could have been a coincidence, precisely as you suggest below. After reporting the issue with Chromium, I also experienced the same issue with several other apps/windows, and, by that point, others had already thoroughly reported the same thing in the linked thread..

I think your original issue report in #2765 related to chromium use, and identified an issue which shouldn't be conflated with this one.

It might well have started out as a Chromium-specific bug, but precisely the same symptoms subsequently manifested themselves after the GUI update less than 24 hours later. There was no way to know, just from observing the symptoms during normal usage, whether it was one bug or two.

[andrewdavidwong]

You also said -

Ok, but I observed the problem before the recent gui-agent update.

and reported that

Chromium browser seems to be the only app/window that freezes

So it cant be a duplicate can it?

Sure it can. What I experienced could have been a coincidence, precisely as you suggest below. After reporting the issue with Chromium, I also experienced the same issue with several other apps/windows, and, by that point, others had already thoroughly reported the same thing in the linked thread..

I think your original issue report in #2765 related to chromium use, and identified an issue which shouldn't be conflated with this one.

It might well have started out as a Chromium-specific bug, but precisely the same symptoms subsequently manifested themselves after the GUI update less than 24 hours later. There was no way to know, just from observing the symptoms during normal usage, whether it was one bug or two.

[andrewdavidwong]

If you're certain that there are actually two distinct bugs here, not just one, then I'm happy to retroactively designate #2765 as specific to the Chromium bug. But it would be a mistake to interpret the initial report about Chromium in that issue as strong evidence that a distinct bug exists, since that report was based on a very small sample size. (It was included since even speculative hints sometimes prove helpful in squashing bugs, and those acting on these reports know when to discount such hints in the face of better evidence.)

[andrewdavidwong]

If you're certain that there are actually two distinct bugs here, not just one, then I'm happy to retroactively designate #2765 as specific to the Chromium bug. But it would be a mistake to interpret the initial report about Chromium in that issue as strong evidence that a distinct bug exists, since that report was based on a very small sample size. (It was included since even speculative hints sometimes prove helpful in squashing bugs, and those acting on these reports know when to discount such hints in the face of better evidence.)

[andrewdavidwong]

If you're certain that there are actually two distinct bugs here, not just one...

On second thought, asking for certainty is too much. I think you're right that the combination of the small-sample-size Chromium observations paired with the pre-GUI-update timing is enough for us to proceed on the assumption that there exist two bugs. 🙂

[andrewdavidwong]

If you're certain that there are actually two distinct bugs here, not just one...

On second thought, asking for certainty is too much. I think you're right that the combination of the small-sample-size Chromium observations paired with the pre-GUI-update timing is enough for us to proceed on the assumption that there exist two bugs. 🙂

[tonsimple]

@andrewdavidwong
the thing that affected me was happening to qube updater (xterm window)

[tonsimple]

@andrewdavidwong
the thing that affected me was happening to qube updater (xterm window)

[marmarek]

Just to be sure: does it still happen with gui-agent 3.2.17?

[marmarek]

Just to be sure: does it still happen with gui-agent 3.2.17?

[andrewdavidwong]

@marmarek:

Just to be sure: does it still happen with gui-agent 3.2.17?

It appears to be fixed! 👍

[andrewdavidwong]

@marmarek:

Just to be sure: does it still happen with gui-agent 3.2.17?

It appears to be fixed! 👍

[andrewdavidwong]

With further use, I noticed it once or twice after posting my previous comment. However, the frequency has been severely reduced. I'll continue to monitor it and comment again if I have anything to add.

[andrewdavidwong]

With further use, I noticed it once or twice after posting my previous comment. However, the frequency has been severely reduced. I'll continue to monitor it and comment again if I have anything to add.

[HW42]

With further use, I noticed it once or twice after posting my previous comment. However, the frequency has been severely reduced. I'll continue to monitor it and comment again if I have anything to add.

On which templte do you observer this?

Do you have noticed a way to trigger this?

Please double check what version of gui-agent you're runing.

[HW42]

With further use, I noticed it once or twice after posting my previous comment. However, the frequency has been severely reduced. I'll continue to monitor it and comment again if I have anything to add.

On which templte do you observer this?

Do you have noticed a way to trigger this?

Please double check what version of gui-agent you're runing.

[andrewdavidwong]

On which templte do you observer this?

Do you have noticed a way to trigger this?

Please double check what version of gui-agent you're runing.

Haven't noticed it again since that post. Will report back if I do.

[andrewdavidwong]

On which templte do you observer this?

Do you have noticed a way to trigger this?

Please double check what version of gui-agent you're runing.

Haven't noticed it again since that post. Will report back if I do.