Walletwasabi: UI is scrambled when unlocking screen

[Giszmo]

General Description

After switching to my account, the Wasabi Wallet window was unrecognizably glitchy. Triggering a refresh by resizing the window resolved the issue.

How To Reproduce?

1. start Wasabi
2. switch to other linux user (switching back directly did not trigger the issue)
3. reload your crashed firefox session (that was what my other account had most handy to move some bits in RAM)
4. switch back to original user

Screenshots

Operating System

Ubuntu 20.04

Wasabi Version

1.1.11.1

Additional comments

I see the potential for this to be a privacy or even security issue for multi tenant systems as I suspect some memory was not handled correctly and just as whatever happened with the RAM on the other account leaked into Wasabi, Wasabi data could leak into available RAM for other users.

[jmacato]

This also happens with VSCode btw, and other apps in Linux... Suspending the system and resuming also does the same.. Somehow the video memory are being corrupted in between. So this probably is a non-issue (at least not a wasabi-specific one.)

[Giszmo]

There should be an upstream issue then. As mentioned in my submission, it might not only be a UX issue but also a privacy or security issue if memory leaks into the wrong context.

[jmacato]

It doesnt leak per se, the GPU Video memory is being rewritten over with garbage data, hence the corruption; It also seems to be common with Skia-based frameworks (Electron/Chromium, Avalonia, etc).

[MaxHillebrand]

I have some of these flickers too, but, in the latest master branch, and especially with the Avalonia v0.10 branch, they are drastically reduced.

[molnard]

Welcome here, thx for the report. You might know we are currently in the finish of a Testing contribution game. Your issue is not critical but something annoying and as you said can be a sign of something critical.

According to our game rules you have to test the release candidate. If you would like to take part in the game and you can repro this in RC2 I will give you one point for this report.
https://github.com/molnard/WalletWasabi/releases/tag/v1.1.12rc2

[stale[bot]]

This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[yahiheb]

@molnard Should this get reopened?

[Giszmo]

On my system I have this issue with Wasabi and one other app I probably rarely use as I just now don't remember which it was. It's not like Linux does that all the time to all the windows. If Wasabi wants to defer this to a different project, please help identify which project to ~pester~offer PRs to get this fixed.

@jmacato said:

It doesnt leak per se, the GPU Video memory is being rewritten over with garbage data,

"garbage data" might be very non-garbage data in some other context and whatever software that wrote this garbage is probably in the position to not write it and read what was there before which is the leak potential. Now there might be ways this glitch could manifest without such a leak being possible but I don't see how you would dismiss this possibility without knowing what's going on exactly.

hence the corruption; It also seems to be common with Skia-based frameworks (Electron/Chromium, Avalonia, etc).

You don't happen to know a bug report in a relevant upstream project?

[jmacato]

@Giszmo Skia or Skiasharp would be a good starting point but we need to have a minimal repro project at least... which is challenging i guess

[molnard]

@Giszmo currently we are upgrading the whole UI engine to Avalonia 0.10. The point is that this issue might not an issue anymore there - so I would say put out the energy to get the new one work instead of fixing things that are going to be replaced anyway. The downward of this that you have to wait for it, is this something critical for you @Giszmo ?

[Giszmo]

not critical for me. just bad ux and a bit scary for the reasons mentioned above.

[molnard]

I added a label to not forget about this after the upgrade was carried out.

[jmacato]

as you can see, this happened on a gtk3 app (KiCAD/eeschema) after suspending and resuming the system. I think this is more likely a driver fault since every app in my system has a version of this bug and it is apparent that this is not within our control anymore. It's the job of the GPU driver to preserve the surface content of framebuffer after suspend and resume of the system, not the app nor the libraries.

Also probably only happens on linux/intel/nvidia GPU's combo.

@molnard let's close this issue.

[molnard]

Thanks for taking a deeper look at this.

[stale[bot]]

This has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.