flameshot screen / full freezes

[tastytea]

Flameshot Version

Flameshot v11.0.0 (aa6b5ea) Compiled with Qt 5.15.2

The same happens with the 11.0.0 release.

Installation Type

Compiled from source

Operating System type and version

Gentoo Linux

Description

flameshot freezes while showing the “Save screenshot” dialog when running flameshot screen or flameshot full. It shows only the window title of the dialog, the only content is the default background color.

flameshot gui works fine, it shows the file dialog fine.

Steps to reproduce

1. Run flameshot screen
2. Stare at frozen dialog for 2 minutes

Screenshots or screen recordings

System Information

$ inxi --width 80 --system --graphics
System:
  Host: ventiloplattform Kernel: 5.15.19-x86_64 x86_64 bits: 64 Desktop: GNOME
  Distro: Gentoo Base System release 2.7
Graphics:
  Device-1: NVIDIA GK106 [GeForce GTX 660] driver: nvidia v: 470.103.01
  Display: server: X.Org 1.21.1.3 driver: loaded: nvidia
  resolution: 1920x1080~60Hz
  OpenGL: renderer: NVIDIA GeForce GTX 660/PCIe/SSE2
  v: 4.6.0 NVIDIA 470.103.01

[borgmanJeremy]

Sorry you probably need to work with the gentoo people on this. It works for other gnome versions and gentoo is something I have no patience for :) Maybe try the flatpak or snap.

[mmahmoudian]

I think @pavel-the-best is the best person to be tagged here to see if he has any ideas considering that he is the maintainer of Flameshot on Gentoo. 🤗

[p4vook]

@tastytea have you created a bug in Gentoo's bugzilla? It would be appreciated, because more context is needed (e.g. environment, use flags, logs), and some of that context isn't really related to flameshot, but rather to Gentoo itself. It will also help maintainers understand that the package isn't yet ready to be stable. I'll try to debug the issue.

[tastytea]

I don't think it is a Gentoo issue. I tried it in a Ubuntu 20.04 VM with aa6b5eac93ee92b58c5ead9404f60a760f667980 and v11.0.0, compiled according to the readme. flameshot screen does nothing and uses all of the CPU cycles it can get. I had not configured anything.

https://user-images.githubusercontent.com/3681516/155264409-411d9e18-f16e-42e4-b495-c625e130a12e.mp4

[mmahmoudian]

@tastytea Now this is is interesting. Thanks for trying to reproduce this in a VM. I'll try to see if I can replicate this on a clean VM and will report back.

[mmahmoudian]

I replicated this on an Ubuntu 20.10 compiled from source

# install dependencies
sudo apt install git g++ cmake build-essential qttools5-dev-tools libqt5svg5-dev qttools5-dev libqt5dbus5 libqt5network5 libqt5core5a libqt5widgets5 libqt5gui5 libqt5svg5 openssl ca-certificates

# create a temp place
mkdir tmp
cd tmp

# clone the repo
git clone https://github.com/flameshot-org/flameshot.git
cd flameshot

# compile
mkdir build
cd build
cmake ../
make

# run the compiled binary
cd src
./flameshot screen

This is what I cloned: aa6b5eac93ee92b58c5ead9404f60a760f667980

and it keeps using the CPU without showing anything (check the time of the process in the screenshot below):

Update: After 16 minutes, it is still running and have not prompted me for the location to save the file... Update 2: I killed the process after 32 minutes of running.

This behavior is not happening on Manjaro KDE x11 and Flameshot v11.0.0 (aa6b5eac)

[veracioux]

I am able to reproduce this on Arch Linux, i3wm, X11, but only when I change the theme from qt's default one.

I'm using the qt5-styleplugins to apply a gtk theme to qt applications. When I launch flameshot screen/full with QT_QPA_PLATFORMTHEME=gtk2, the dialog freezes. If I use the default theme (QT_QPA_PLATFORMTHEME=qt), the dialog works correctly.

Maybe Gentoo and Ubuntu do something similar out of the box?

[tastytea]

It still freezes here on Gentoo (i3wm, X11) and Ubuntu with QT_QPA_PLATFORMTHEME=qt. On Ubuntu the variable was unset before and on Gentoo I set it to gtk2.

But when I set XDG_CURRENT_DESKTOP=KDE (was GNOME before on both) and QT_QPA_PLATFORMTHEME=qt (or unset it) it works.

[p4vook]

I wasn't able to reproduce this issue on Wayland. Perhaps, it is X11-only?

[p4vook]

UPD: on my machine XDG_CURRENT_DESKTOP set to any value than default (sway in my case) results in crash. QT_QPA_PLATFORMTHEME seems to have no effect.

[mmahmoudian]

@pavel-the-best this VM is on Wayland

[dummys]

same problem here with Archlinux under AwesomeWM. My problem is when I use it from awesome like:

awful.key({ altkey }, "p", function() os.execute("/bin/bash -c 'flameshot gui -p ~/screenshots'") end),

When doing this, the screen to select is visible, when selected and click on the "ok", then it freezes all the screen. I have to manually kill flameshot from another TTY to recover my session.

Running it directly from my shell, it works as expected. Want to help debug, but don't know where to start.

[mmahmoudian]

@dummys just as a heads up, when you put things in single quote, bash will not expand them. So '~' will not get translated to '${HOME}'. In your case I would switch the single quotes with double quotes.

[dummys]

@dummys just as a heads up, when you put things in single quote, bash will not expand them. So '~' will not get translated to '${HOME}'. In your case I would switch the single quotes with double quotes.

ok thanks but it was working since now. so you will do like this: '/bin/bash -c "flameshot gui -p ~/screenshots"' ?

[mmahmoudian]

@dummys I made a mistake in my previous comment. What I said is correct but it does not concern you because the single quoted string is input of /bin/bash and that's why it has worked for you. You don't need to change your script, although changing it does not hurt either. I'm going to mark your last message and my last two messaged as "off-topic" since they don't contribute to the thread here.

[dummys]

yup, but how to debug our issue then ? Is there some debug mode to have some logs ? Because in my case it just freeze the screen.

[mmahmoudian]

Is there some debug mode to have some logs ?

There is no debugging mode or extra verbosity [yet].

[applejag]

@dummys same problem here with Archlinux under AwesomeWM. My problem is when I use it from awesome like:

awful.key({ altkey }, "p", function() os.execute("/bin/bash -c 'flameshot gui -p ~/screenshots'") end),

When doing this, the screen to select is visible, when selected and click on the "ok", then it freezes all the screen. I have to manually kill flameshot from another TTY to recover my session.

Running it directly from my shell, it works as expected. Want to help debug, but don't know where to start.

I got it working on AwesomeWM by using awful.spawn instead of os.execute. With os.execute I had the same symptom where AwesomeWM freezes.

awful.key({ }, "Print", function() awful.spawn("flameshot gui") end,
          {description = "take a screenshot", group = "hotkeys"}),

I'm just launching flameshot gui directly instead of doing it via /bin/bash as you are, but that shouldn't matter.

[dummys]

@jilleJr bro you saved my life ahahah :D thanks for such nice workaround. We have just to not use ~ and use an absoluth path, but it works. We can close the isuse.

[applejag]

@jilleJr bro you saved my life ahahah :D thanks for such nice workaround. We have just to not use ~ and use an absoluth path, but it works. We can close the isuse.

Lol life saving comment :P

Ah yes allowing use of ~ requires it to be wrapped with a call to bash or sh, my bad. E.g:

awful.key({ }, "Print", function() awful.spawn("/bin/bash -c 'flameshot gui -p ~/screenshots'") end,
          {description = "take a screenshot", group = "hotkeys"}),

[svonidze]

The same happens for me as well almost every time I use Flameshot to capture something. The hanging stated to happen when I attached a new monitor (HP Omen 32C) to my Lenovo W540

Flameshot may hang for few second, few minutes, once I even tied to wait ~10 mins No errors in terminal if ran Flameshot from there. The host is

Description: Linux Mint 21.2 Release: 21.2 Codename: victoria