Likely just noise. Could connect mount-observe to be sure.
Per @jamesh, also likely just noise. Could update the apparmor profile temporarily to have /var/lib/snapd/desktop/icons/{,**} r, to be sure.
I suspect this is the culprit and the app isn’t handling the access denied gracefully. Try connecting the screencast-legacy interface.
The snap doesn’t seem to plug that currently, so perhaps that’s the issue. If I get some more time I will try adding that interface to the snap
Adding the screencast-legacy interface doesn’t seem to fix the issue.
Since the app also crashes in devmode, can we rule out that it’s a confinement issue?
This appears to be a regression in snapd. The app hasn’t been updated since I last tried it, and it used to work. Is there a way for me to test previous snapd versions?
Seems limited to 19.04. I’m on 19.10 and the drawing app works fine.
Anything in dmesg when it crashes?
Nothing new:
[ 5894.420505] audit: type=1400 audit(1571255503.291:1408): apparmor="ALLOWED" operation="open" profile="snap.drawing.drawing" name="/proc/15266/mounts" pid=15266 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[ 5894.638403] audit: type=1400 audit(1571255503.507:1409): apparmor="ALLOWED" operation="open" profile="snap.drawing.drawing" name="/var/lib/snapd/desktop/icons/" pid=15266 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
I can confirm it also works in 18.04 proper.
I can confirm it doesn’t work on my 18.04 (neither stable or edge). How can I help?
journalctl output follows.
audit[13686]: AVC apparmor="DENIED" operation="open" profile="snap.drawing.drawing" name="/proc/13686/mounts" pid=13686 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit: type=1400 audit(1571272770.990:166): apparmor="DENIED" operation="open" profile="snap.drawing.drawing" name="/proc/13686/mounts" pid=13686 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
audit[13686]: AVC apparmor="DENIED" operation="open" profile="snap.drawing.drawing" name="/var/lib/snapd/desktop/icons/" pid=13686 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
audit: type=1400 audit(1571272771.314:167): apparmor="DENIED" operation="open" profile="snap.drawing.drawing" name="/var/lib/snapd/desktop/icons/" pid=13686 comm="drawing" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
dbus-daemon[3693]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gnome/Shell/Screenshot" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.21" pid=13686 label="snap.drawing.drawing" peer_pid=3819 peer_label="unconfined"
dbus-daemon[3693]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/org/gnome/Shell/Screenshot" interface="org.freedesktop.DBus.Properties" member="GetAll" mask="send" name=":1.21" pid=13686 label="snap.drawing.drawing" peer_pid=3819 peer_label="unconfined"
$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.3 LTS"
What separates this snap from others is its use of the gnome-3-32-1804 platform-snap. I have a few test snaps that use this particular content plug that have started failing just like this too.
I’m certain these snaps were all working fine last Friday (11-10-2019) as I was testing them particularly to release the now stable gnome-3-32-1804 (Installing older versions of drawing and/or the gnome-3-32-1804 snap doesn’t fix things either btw).
Now this is weird, I can reproduce this on Disco and Eoan, but not on Bionic. Then, even weirder, if I run Disco or Eoan in a VM with ‘3D Acceleration’ disabled, it works! On the surface, it would seem this is something GL related. Though, LIBGL_ALWAYS_SOFTWARE=1 snap run drawing does not work.
UPDATE:
strace reveals that the last thing the snap does before crashing is load Yaru icons. So on a hunch I decided to try switching my Applications theme to Adwaita - no luck, still crashed. Switched to HighContrast, and… it worked… no crash!
I then noticed that although the snap was working on Bionic, the Ambiance theming looked off, so I switched theme to Adwaita and boom! crash.
Now, I’m just brain dumping here in case someone has a good idea. I’m not sure that this is not gnome-3-32-1804’s (my) fault. Either way, these notes will come in handy 
I tried the same, after your results, and it works ideed - accel disabled VM, 18.04, and Drawing works. I can see some visual glitches though - the red “discard” button, “save” button top bleeding to the title bar and others… I’m using Adwaita dark theme.
Things just keep getting stranger… I just installed Eoan fresh on one of my machines, installed updates, installed the drawing snap - works perfectly. No issues whatsoever.
UPDATE:
Alright, the snap started core dumping on the above machine.
I’m pretty sure the iso I used to install was a daily build from 12th October, so it struck me that perhaps one of the seeded snaps that came with the iso was working and subsequently broke with a refresh some time after.
I noticed that the gtk-common-themes snap updated from 1313 to 1353 so, considering the theming issues we saw, I tried a snap revert gtk-common-themes, and yeah, fixed, no more crash.
Tried this, reverted to 1313 and even forwarded to 1358 (edge), no luck: still same problem.
Ah, do you happen to be on Adwaita or Yaru-light? I just noticed that on 1313, these themes still cause the crash, while standard Yaru, Yaru-dark, and the HighContrast themes allow drawing to launch just fine.
You’re absolutely right, I was using Adwaita. Changing to High Contrast, for example, makes Drawing work; changing back to Adwaita while Drawing is open crashes the app.
Very strange…
It seems that latest gnome-3-32-1804 (0+git.635fbdc build 75) made Drawing work. Hope it gets stable now.
Hey @ivo.cavalcante, yeah the issue was narrowed down yesterday. We should be good for all snaps that use gnome-3-32-1804 now. Thanks for your help
Not at all, I’m the one who should thank you!
@kenvandine are you aware that upstream have “issues” with the snap version? - apparently the v0.5 should not have been snapped https://github.com/maoschanz/drawing/issues/125
apparently the v0.5 should not have been snapped
He was packaging the master branch, which is the “normal” thing to do (i suppose) for the edge channel. But here it was packaged as stable too: users only had the version 0.5 with all my work-in-progress. My experiments were probably fun to watch, but not very reliable to use. Meanwhile the stable versions tagged on the branch 0.4 were ignored
The issue is fixed, in a way: he changed a few things, and the version displayed by the snap store is now 0.4.7-bunchofnumbers, which is from the branch 0.4, which isn’t master, so it’s cool.
But… the versioning of that package still looks quite chaotic: both snap channels have this weird version since december 2019 and the packaged code isn’t even really from the tag 0.4.7, which is weird. You can see that because when you install it, the “about” dialog says 0.4.8
are you aware that upstream have “issues” with the snap version?
the link to the snapstore in my readme should rickroll you, which is a stronger message to snapcraft than any of my closed issues
The last version i published is 0.6.3, which is very different (far more reliable, more tools, many more options, finally zooming, more translations, etc.). As an user, you should use flatpak (or the PPA) to get it.
I’ve updated the snap to be based on the 0.6 branch.
The snap version is based on the output of “git describe”, so it takes the latest tag in the branch and appends a hash that will help show which commit it was built from. For example, the version I just published is 0.6.3-4-g5b2ec5d453 however the version in the about dialog does say it’s 0.6.4 because meson.build in the 0.6 branch already reflects 0.6.4.
I have no idea if this is an issue or not, but I saw it reported on askubuntu & the answer was from another user reporting the same issue.
https://askubuntu.com/questions/1447248/drawing-1-0-1-not-working
Since a few days the app doesn’t start. I have Ubuntu 22. I tried to uninstall and re-install the app via snap, but, even after that, nothing happens when I start the app. Here is my terminal output.
user@user-All-Series:~$ drawing &
[1] 212365
user@user-All-Series:~$ /snap/drawing/27/gnome-platform/command-chain/desktop-launch: /snap/drawing/27/usr/bin/drawing: /snap/gnome-42-2204-sdk/current/usr/bin/python3: bad interpreter: No such file or directory
/snap/drawing/27/gnome-platform/command-chain/desktop-launch: line 603: /snap/drawing/27/usr/bin/drawing: Success
Answer provided is
I had the same problem with the Gnome Drawing app, but I found the solution. Installing
gnome-42-2204-sdksolves this as it provides the necessarily libraries needed for gnome 42 apps.
I’ve not tested this, so apology if this is unhelpful, but it looks like it would benefit from explore (thus this post). All details pasted from askubuntu link.