Bug#991320: flameshot crashing on startup

[allan]

many thanks, dennis - if you need anything else feel free to reach out.

On Thu, Jul 22, 2021 at 3:33 PM Dennis Filder  wrote:
>
> Okay, I can reproduce the crash now with that setting.

Bug#991320: flameshot crashing on startup

[Dennis Filder]

Control: tag -1 patch upstream
X-Debbugs-CC: allan grossman 

On Wed, Jul 21, 2021 at 04:47:17PM -0500, allan wrote:

> [General]
> disabledTrayIcon=true

Okay, I can reproduce the crash now with that setting.  The update
check silently assumes that tray and its associated member variables
have been initialized.

The attached patch at least prevents flameshot from crashing.  A
proper fix would ensure that any enabled feature that depends on
disabled features automatically gets disabled, too.

Regards.
Description: Fix nullptr dereference
 It occurs when the user has disabledTrayIcon=true, but also
 checkForUpdates=true (explicitly or the default).
Last-Update: 2021-07-22
Author: Dennis Filder 
--- a/src/core/controller.cpp
+++ b/src/core/controller.cpp
@@ -192,7 +192,8 @@
 m_appLatestUrl = json["html_url"].toString();
 QString newVersion =
   tr("New version %1 is available").arg(m_appLatestVersion);
-m_appUpdates->setText(newVersion);
+if (m_appUpdates != nullptr)
+m_appUpdates->setText(newVersion);
 if (m_showCheckAppUpdateStatus) {
 sendTrayNotification(newVersion, "Flameshot");
 QDesktopServices::openUrl(QUrl(m_appLatestUrl));

Bug#991320: flameshot crashing on startup

[allan]

this link and the link above only address the tray icon - nothing on
the network thing on github bugtracker.  both of these bugs are
closed.

https://github.com/flameshot-org/flameshot/issues/1721

amusingly, if i rename flameshot.ini and start the flameshot daemon in
the background (which is how i had it set up in openbox autostart)
flameshot works as expected.  diff between default config and mine -

wizard@wizard-fujitsu:~/.config/flameshot$ diff flameshot.ini
flameshot.ini.broken
2,5c2,7
< disabledTrayIcon=false
< drawColor=#ff
< drawThickness=0
< showStartupLaunchMessage=true
---
> # disabledTrayIcon=true
> drawColor=#00ff00
> drawThickness=9
> savePath=/media/internal/temp
> startupLaunch=false
> # checkForUpdates=false

using the config i had that's been working for over a year flameshot
daemon (flameshot &) crashes if checkForUpdates=false.

starting 'flameshot gui' without the daemon running in the background
crashes with either config.





On Thu, Jul 22, 2021 at 8:43 AM allan  wrote:
>
> i think i figured it out.  looks like it's upstream and wontfix.
>
> https://github.com/flameshot-org/flameshot/issues/1730



-- 
we see things not as they are, but as we are.
 -- anais nin

Bug#991320: flameshot crashing on startup

[allan]

i think i figured it out.  looks like it's upstream and wontfix.

https://github.com/flameshot-org/flameshot/issues/1730

Bug#991320: flameshot crashing on startup

[allan]

not able to choke my network as option isn't available in kernel
module, connman or router.  using iw to throttle bitrate seems to be
unsupported by this intel chipset or at least it's not in the list of
supported commands if you do 'iw list'.

flameshot 0.9 appimage took some digging to find but also crashes -

wizard@wizard-fujitsu:~/temp$ ./Flameshot-0.9.0.x86_64.AppImage
Run experimental self-contained bundle
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
Segmentation fault
wizard@wizard-fujitsu:~/temp$

purged 0.9 and installed current flameshot 0.10.0.rc1-1 deb from
github and it works as expected.

then i purged 0.10 and reinstalled 0.9 from sid repo in case we need
more testing.  if i really need to run flameshot i can just disable
checking for upgrades for the time being.

Bug#991320: flameshot crashing on startup

[allan]

oh - almost forgot.  on the tray icon -

[General]
disabledTrayIcon=true
drawColor=#00ff00
drawThickness=9
savePath=/media/internal/temp
startupLaunch=false
# checkForUpdates=false

Bug#991320: flameshot crashing on startup

[allan]

> No, it shows exactly what I was looking for:

this is why i should listen to developers.  i would have been tearing
stuff apart already  :)

flameshot worked properly the last time i used it and for at least a
year before,  last time i used it was maybe five days before i filed
the bug.

network here is 200/10mb and latency usually runs 40-50ms which ain't
great but ain't awful either.

i think what i'll do is shut off everything but 802.11b and play a
little which may take a little network configurating if i can't do it
on the wireless kernel module or connman; i can't think of a way to
add latency as i'm already doing wireless. happy to do the appimage
thing (that would eliminate openbox, right?) but i really would rather
not install snap infrastructure.

may be noon est or so before i'm able to play with this again so
thanks and have a good evening.

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

On Wed, Jul 21, 2021 at 02:20:37PM -0500, allan wrote:
> this doesn't look real helpful - looks like I may need to install some
> source code but not sure which code other than flameshot -

No, it shows exactly what I was looking for:

> (gdb) backtrace 5
> #0  QAction::setText (this=0x0, text=...)
> at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116

The this pointer is null, i.e. m_appUpdates is still uninitialized
when the call to setText() happens.  That is something the upstream
devs can't easily argue away.  But the question is: Why is it
null/uninitialized?  Either because Openbox lacks a feature Qt needs
for making system trays (and flameshot doesn't properly check for that
failing), or because your Internet connection is too fast leading to
the wrong race condition outcome.  Was flameshot working normally with
Openbox in the past?

You could also try if lowering your connection speed (latency,
throughput) resolves the issue.  Maybe going to a coffee shop or some
other place with slow Internet is the easiest way.  Otherwise you'll
have to fiddle with netem[0,1] or the firewall and find ways to
throttle speed that way (I can't help you with that).

Also: I saw that AppImages[2] are provided, but apparently not for
version 0.10.0[3].  It would have been valuable to know if the error
occurs with that, too.  Maybe you can try the Snap image (I have no
experience with using that).  If running that via shell is for some
reason not possible segfaults should show up in the output of dmesg.

Regards.

0: https://stackoverflow.com/questions/24729545/how-to-tc-filter-with-netem
1: https://wiki.linuxfoundation.org/networking/netem
2: https://flameshot.org/guide/installation/installation-linux/#appimage
3: https://github.com/flameshot-org/flameshot/releases/tag/v0.10.0

Bug#991320: flameshot crashing on startup

[allan]

this doesn't look real helpful - looks like I may need to install some
source code but not sure which code other than flameshot -

Reading symbols from flameshot...
Reading symbols from
/usr/lib/debug/.build-id/5c/2acff54f5aa466e019691671622f39294b075d.debug...
(gdb) start
Temporary breakpoint 1 at 0x3dc60: file ./src/main.cpp, line 54.
Starting program: /usr/bin/flameshot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe338) at ./src/main.cpp:54
54 ./src/main.cpp: No such file or directory.
(gdb) break Controller::handleReplyCheckUpdates(QNetworkReply*)
Breakpoint 2 at 0x555b1720: file ./src/core/controller.cpp, line 160.
(gdb) continue
Continuing.
[New Thread 0x72a64700 (LWP 155677)]
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
[New Thread 0x71e16700 (LWP 155678)]
[New Thread 0x715e5700 (LWP 155679)]
[New Thread 0x70a08700 (LWP 155680)]
[New Thread 0x7fffe3fff700 (LWP 155681)]

Thread 1 "flameshot" hit Breakpoint 2, Controller::handleReplyCheckUpdates (
this=0x55642160 , reply=0x55703b60)
at ./src/core/controller.cpp:160
160 ./src/core/controller.cpp: No such file or directory.
(gdb) break QAction::setText(QString const&)
Breakpoint 3 at 0x7787b000: file
../../include/QtCore/../../src/corelib/tools/qscopedpointer.h, line
116.
(gdb) continue
Continuing.

Thread 1 "flameshot" hit Breakpoint 3, QAction::setText (this=0x0, text=...)
at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116
116 ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h: No
such file or directory.
(gdb) backtrace 5
#0  QAction::setText (this=0x0, text=...)
at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116
#1  0x555b2267 in Controller::handleReplyCheckUpdates (
this=0x55642160 , reply=0x7fffd120)
at ./src/core/controller.cpp:195
#2  0x76d895a6 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x77de9ad2 in QNetworkAccessManager::finished(QNetworkReply*) ()
   from /lib/x86_64-linux-gnu/libQt5Network.so.5
#4  0x77deae17 in ?? () from /lib/x86_64-linux-gnu/libQt5Network.so.5
(More stack frames follow...)
(gdb) continue
Continuing.
[Thread 0x7fffe3fff700 (LWP 155681) exited]

Thread 1 "flameshot" received signal SIGSEGV, Segmentation fault.
QAction::setText (this=0x0, text=...) at kernel/qaction.cpp:714
714 kernel/qaction.cpp: No such file or directory.
(gdb) quit
A debugging session is active.

Inferior 1 [process 155542] will be killed.

Quit anyway? (y or n) y
wizard@wizard-laptop:/tmp$

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

Okay, download the debug symbols from:
http://debug.mirrors.debian.org/debian-debug/pool/main/f/flameshot/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb
http://debug.mirrors.debian.org/debian-debug/pool/main/q/qtbase-opensource-src/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb

Put them in /tmp and make them world-readable, then install as root
(e.g. apt install /tmp/flameshot-dbgsym_0.9.0+ds1-1_amd64.deb 
/tmp/libqt5widgets5-dbgsym_5.15.2+dfsg-9_amd64.deb).

Then run "gdb flameshot" again and type:

 start
 break Controller::handleReplyCheckUpdates(QNetworkReply*)
 continue
 break QAction::setText(QString const&)
 continue
 backtrace 5

The output should look like this.

#0  QAction::setText (this=0x558b52b0, text=...) at 
../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116
#1  0x555b2267 in Controller::handleReplyCheckUpdates 
(this=0x55642160 , reply=0x7fffcbe0) at 
./src/core/controller.cpp:195
#2  0x76d755a6 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#3  0x77dd5ad2 in QNetworkAccessManager::finished(QNetworkReply*) () 
from /lib/x86_64-linux-gnu/libQt5Network.so.5
#4  0x77dd6e17 in ?? () from /lib/x86_64-linux-gnu/libQt5Network.so.5

Bug#991320: flameshot crashing on startup

[allan]

no joy here either -

Reading symbols from flameshot...
(No debugging symbols found in flameshot)
(gdb) backtrace 5
No stack.
(gdb)

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

On Wed, Jul 21, 2021 at 12:51:16PM -0500, allan wrote:
> couldn't get past "start" -

Okay, omit "start" and "continue" and just type the "backtrace 5" command.

Bug#991320: flameshot crashing on startup

[allan]

couldn't get past "start" -

wizard@wizard-laptop:~$ gdb flameshot
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from flameshot...
(No debugging symbols found in flameshot)
(gdb) start
Function "main" not defined.
Make breakpoint pending on future shared library load? (y or [n])
Starting program: /usr/bin/flameshot
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x72a64700 (LWP 122428)]
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
[New Thread 0x71e16700 (LWP 122429)]
[New Thread 0x715e5700 (LWP 122430)]
[New Thread 0x70a08700 (LWP 122431)]
[New Thread 0x7fffe3fff700 (LWP 122432)]

Thread 1 "flameshot" received signal SIGSEGV, Segmentation fault.

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

After looking at the code I'm fairly certain the segfault happens in
Controller::handleReplyCheckUpdates() in src/core/controller.cpp which
gets passed to the connect() call.  The culprit is probably line 195:

m_appUpdates->setText(newVersion);

Since I cannot reproduce it I can't look at it in a debugger.  Allan,
if you want you can try running this in gdb like so:

gdb flameshot

and then in gdb

start
continue
backtrace 5

and give us the output.  I speculate for people with very fast
Internet connections the call to setText() happens before m_appUpdates
gets initialized, maybe because the compiler reorders statements.

A fix could consist of one of these changes:

 * Return immediately from
   src/core/controller.cpp:Controller::getLatestAvailableVersion() to
   disable update checks altogether.

 * Initialize res with false instead of true in
   src/utils/confighandler.cpp:ConfigHandler::checkForUpdates()
   to turn off update checks by default.

Regards.

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 02:54:26PM -0500, allan wrote:
> Setting checkForUpdates=false resolved the issue.  Thanks, Dennis  :)

Okay, that is good to know.  I personally feel like that option should
be set to false by default in Debian (don't the pop-ups annoy the hell
out of people?).

Of course the segfault as a problem remains, but that is upstream's
issue.

Also I suspect I know why I couldn't reproduce this: I sit behind a
proxy, so maybe Qt's networking code behaves differently then.  There
is a lot going on in the strace log, but the crash happened after the
hostname for api.github.com was resolved.

Regards.

Bug#991320: flameshot crashing on startup

[allan]

Setting checkForUpdates=false resolved the issue.  Thanks, Dennis  :)

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 02:16:16PM -0500, allan wrote:
> apt log shows qt libraries updated three days ago - these wouldn't
> have made it to Bullseye yet.
>
> Start-Date: 2021-07-17  08:52:52
> Requested-By: wizard (1000)
> Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
> (14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
> (5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
> automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
> libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
> (20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
> automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
> libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
> qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
> libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
> qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
> libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
> qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
> End-Date: 2021-07-17  08:52:58

All those libraries are on my system already.  I think this late in
the freeze some libraries get fast-tracked into testing on request.

> Backtrace:
> /lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
> flameshot(+0x5e267)[0x55efcb2b6267]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
> /lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
> /lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
> ...

The only reason for flameshot to touch the network (which it
presumably does here) is to check for updates.  Try setting
"checkForUpdates" to "false" in ~/.config/flameshot/flameshot.ini --
maybe this will preclude the codepath in question from being taken.
Let us know if this fixes it for you -- if not, then I don't really
see what more could be done here.  Maybe running

strace -s2048 -f -e 'trace=%net' -o /tmp/flameshot.strace flameshot

will reveal what network facility it tries to contact before it crashes.

Regards,
Dennis.

Bug#991320: flameshot crashing on startup

[allan]

apt log shows qt libraries updated three days ago - these wouldn't
have made it to Bullseye yet.

Start-Date: 2021-07-17  08:52:52
Requested-By: wizard (1000)
Install: libqt5quickwidgets5:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtquick-window2:amd64 (5.15.2+dfsg-6, automatic), sox:amd64
(14.4.2+git20190427-2, automatic), qml-module-qt-labs-settings:amd64
(5.15.2+dfsg-6, automatic), qml-module-qtmultimedia:amd64 (5.15.2-3,
automatic), libqt5multimediaquick5:amd64 (5.15.2-3, automatic),
libsox3:amd64 (14.4.2+git20190427-2, automatic), mystiq:amd64
(20.03.23-2), qml-module-qt-labs-folderlistmodel:amd64 (5.15.2+dfsg-6,
automatic), libsox-fmt-alsa:amd64 (14.4.2+git20190427-2, automatic),
libqt5multimediawidgets5:amd64 (5.15.2-3, automatic),
qml-module-qtquick-privatewidgets:amd64 (5.15.2-2, automatic),
libsox-fmt-base:amd64 (14.4.2+git20190427-2, automatic),
qml-module-qtquick2:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtquick-dialogs:amd64 (5.15.2-2, automatic),
libqt5qmlworkerscript5:amd64 (5.15.2+dfsg-6, automatic),
qml-module-qtqml:amd64 (5.15.2+dfsg-6, automatic)
End-Date: 2021-07-17  08:52:58

GDK_BACKEND=x11 flameshot still segfaulted.  I'm running X11.

catchsegv was too big for a bug report so I attached it to email.
*** Segmentation fault
Register dump:

 RAX:    RBX: 55efcb346160   RCX: 55efccfe6010
 RDX: 0004   RSI: 7ffed987dbb0   RDI: 
 RBP: 7ffed987dbc0   R8 : 55efcd1e84e0   R9 : 0020
 R10: 0006   R11: 0006   R12: 7ffed987dbb0
 R13: 7ffed987db90   R14: 55efcd0b67f8   R15: 7ffed987db98
 RSP: 7ffed987db00

 RIP: 7fd8dbd48005   EFLAGS: 00010206

 CS: 0033   FS:    GS: 

 Trap: 000e   Error: 0004   OldMask:    CR2: 0008

 FPUCW: 037f   FPUSW:    TAG: 7fd8
 RIP: dae37fd8   RDP: dbbe8140

 ST(0)     ST(1)  
 ST(2)     ST(3)  
 ST(4)     ST(5)  b000
 ST(6)  d000   ST(7) d000 d000
 mxcsr: 1fa0
 XMM0:  61697320 XMM1:  61697320
 XMM2:  61697320 XMM3:  61697320
 XMM4:  61697320 XMM5:  61697320
 XMM6:  61697320 XMM7:  61697320
 XMM8:  61697320 XMM9:  61697320
 XMM10: 61697320 XMM11: 61697320
 XMM12: 61697320 XMM13: 61697320
 XMM14: 61697320 XMM15: 61697320

Backtrace:
/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN7QAction7setTextERK7QString+0x5)[0x7fd8dbd48005]
flameshot(+0x5e267)[0x55efcb2b6267]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
/lib/x86_64-linux-gnu/libQt5Network.so.5(_ZN21QNetworkAccessManager8finishedEP13QNetworkReply+0x42)[0x7fd8dc2b6ad2]
/lib/x86_64-linux-gnu/libQt5Network.so.5(+0x44e17)[0x7fd8dc2b7e17]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x2e45a6)[0x7fd8db2545a6]
/lib/x86_64-linux-gnu/libQt5Network.so.5(+0xa08b8)[0x7fd8dc3138b8]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN7QObject5eventEP6QEvent+0x291)[0x7fd8db249ff1]
/lib/x86_64-linux-gnu/libQt5Widgets.so.5(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0x7f)[0x7fd8dbd4c15f]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent+0x12a)[0x7fd8db21dfca]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData+0x171)[0x7fd8db220a01]
/lib/x86_64-linux-gnu/libQt5Core.so.5(+0x305e93)[0x7fd8db275e93]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x25b)[0x7fd8da050e6b]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x52118)[0x7fd8da051118]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2f)[0x7fd8da0511cf]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE+0x5f)[0x7fd8db27551f]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x12b)[0x7fd8db21c98b]
/lib/x86_64-linux-gnu/libQt5Core.so.5(_ZN16QCoreApplication4execEv+0x90)[0x7fd8db224c00]
flameshot(+0x3f9f6)[0x55efcb2979f6]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7fd8daa6dd0a]
flameshot(+0x41c8a)[0x55efcb299c8a]

Memory map:

55efcb258000-55efcb289000 r--p  08:11 12324114 /usr/bin/flameshot
55efcb289000-55efcb2f3000 r-xp 00031000 08:11 12324114 /usr/bin/flameshot
55efcb2f3000-55efcb33b000 r--p 0009b000 08:11 12324114 /usr/bin/flameshot
55efcb33b000-55efcb346000 r--p 000e2000 08:11 12324114 /usr/bin/flameshot
55efcb346000-55efcb347000 rw-p 000ed000 08:11 12324114 /usr/bin/flameshot
55efccfe6000-55efcd2c4000 rw-p  00:00 

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

On Tue, Jul 20, 2021 at 01:16:39PM -0500, allan wrote:
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.

When exactly did it break and what packages did you install that could
have made it break?  /var/log/apt/history.log should have the answer.

Again: Does running flameshot with GDK_BACKEND=x11 fix it for you --
yes or no?  Do you run wayland or xorg?

Also, you say it crashes.  How does it crash?  Segfault?  What is the
exact message?  What is the output if you run it like this?:

catchsegv flameshot

You have to give us something to work with.

Bug#991320: flameshot crashing on startup

[Boyuan Yang]

在 2021-07-20星期二的 13:16 -0500，allan写道：
> This has only been broken for a couple of days - there's a strong
> possibility that whatever broke it hasn't made it to Bullseye yet.
> This appears to be an upstream bug because a Manjaro user running same
> version of flameshot and Qt is experiencing same behavior and as
> mentioned, it broke a couple of days ago.

This is exactly the merit of release freeze -- anyway, you may check what has
been updated in unstable in the past few days. Please let me know if you have
any findings.

As the packager, I would be targeting on flameshot 0.10.0 when the freeze is
over and it would be meaningful if we could analyze whether it's still broken
with new release then.

Thanks,
Boyuan Yang

> On Tue, Jul 20, 2021 at 11:54 AM Dennis Filder  wrote:
> > 
> > X-Debbugs-CC: allan grossman 
> > 
> > I can't reproduce this under current Bullseye KDE/xorg -- flameshot
> > behaves absolutley normally.  It could be a Wayland issue, and
> > flameshot's Wayland support is apparently still experimental.
> > 
> > Let us know if running flameshot like so fixes this for you:
> > 
> >     GDK_BACKEND=x11 flameshot
> > 
> > Regards,
> > Dennis Filder


signature.asc
Description: This is a digitally signed message part

Bug#991320: flameshot crashing on startup

[allan]

More information.

Qt5 updates on these machines was installed three days ago; since I
update daily I'm fairly certain these updates haven't made it to
Bullseye yet.

Bug#991320: flameshot crashing on startup

[allan]

This has only been broken for a couple of days - there's a strong
possibility that whatever broke it hasn't made it to Bullseye yet.
This appears to be an upstream bug because a Manjaro user running same
version of flameshot and Qt is experiencing same behavior and as
mentioned, it broke a couple of days ago.

On Tue, Jul 20, 2021 at 11:54 AM Dennis Filder  wrote:
>
> X-Debbugs-CC: allan grossman 
>
> I can't reproduce this under current Bullseye KDE/xorg -- flameshot
> behaves absolutley normally.  It could be a Wayland issue, and
> flameshot's Wayland support is apparently still experimental.
>
> Let us know if running flameshot like so fixes this for you:
>
> GDK_BACKEND=x11 flameshot
>
> Regards,
> Dennis Filder



-- 
we see things not as they are, but as we are.
 -- anais nin

Bug#991320: flameshot crashing on startup

[Dennis Filder]

X-Debbugs-CC: allan grossman 

I can't reproduce this under current Bullseye KDE/xorg -- flameshot
behaves absolutley normally.  It could be a Wayland issue, and
flameshot's Wayland support is apparently still experimental.

Let us know if running flameshot like so fixes this for you:

GDK_BACKEND=x11 flameshot

Regards,
Dennis Filder

Bug#991320: flameshot crashing on startup

[allan]

Correction.

"flameshot &" is in openbox autostart, "flameshot gui -p
/home/username/temp" is mapped to hotkey in ~/.config/openbox/rc.xml -
this configuration has been working for more than a year.

On Tue, Jul 20, 2021 at 10:18 AM allan grossman  wrote:
>
> Package: flameshot
> Version: 0.9.0+ds1-1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: wizard10...@gmail.com
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> Have flameshot gui -p /home/username/temp set in openbox autostart.  Mapped 
> hotkeys were not responding.
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> This probably isn't a flameshot bug but I'm not sure where it goes - 
> flameshot crashes when started in openbox autostart or from terminal session 
> and have duplicated the error on two Sid machines.  If you execute 
> "dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will 
> start for about half a second and then crash, which is better than running in 
> a terminal session where it won't display GUI at all before crashing.
>
>* What was the outcome of this action?
>
> flameshot still not working.
>
>* What outcome did you expect instead?
>
> Expected flameshot to run as normal  :)
>
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers unstable
>   APT policy: (1001, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages flameshot depends on:
> ii  hicolor-icon-theme0.17-2
> ii  libc6 2.31-13
> ii  libfmt7   7.1.3+ds1-5
> ii  libgcc-s1 10.2.1-6
> ii  libqt5core5a  5.15.2+dfsg-9
> ii  libqt5dbus5   5.15.2+dfsg-9
> ii  libqt5gui55.15.2+dfsg-9
> ii  libqt5network55.15.2+dfsg-9
> ii  libqt5svg55.15.2-3
> ii  libqt5widgets55.15.2+dfsg-9
> ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.1+ds-2.1
> ii  libstdc++610.2.1-6
>
> flameshot recommends no packages.
>
> Versions of packages flameshot suggests:
> ii  ca-certificates  20210119
> ii  openssl  1.1.1k-1
>
> -- no debconf information



-- 
we see things not as they are, but as we are.
 -- anais nin

Bug#991320: flameshot crashing on startup

[allan grossman]

Package: flameshot
Version: 0.9.0+ds1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: wizard10...@gmail.com

Dear Maintainer,

   * What led up to the situation?

Have flameshot gui -p /home/username/temp set in openbox autostart.  Mapped 
hotkeys were not responding.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

This probably isn't a flameshot bug but I'm not sure where it goes - flameshot 
crashes when started in openbox autostart or from terminal session and have 
duplicated the error on two Sid machines.  If you execute 
"dbus-update-activation-environment DISPLAY XAUTHORITY" flameshot gui will 
start for about half a second and then crash, which is better than running in a 
terminal session where it won't display GUI at all before crashing.
 
   * What was the outcome of this action?

flameshot still not working.
   
   * What outcome did you expect instead?

Expected flameshot to run as normal  :)
   

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (1001, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flameshot depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.31-13
ii  libfmt7   7.1.3+ds1-5
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5dbus5   5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5svg55.15.2-3
ii  libqt5widgets55.15.2+dfsg-9
ii  libspdlog1 [libspdlog1-fmt7]  1:1.8.1+ds-2.1
ii  libstdc++610.2.1-6

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20210119
ii  openssl  1.1.1k-1

-- no debconf information