Version-Release number of selected component: screenkey-1.2-4.fc34 Additional info: reporter: libreport-2.15.2 cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-gnome-screenkey-11299.scope cmdline: /usr/bin/python3 -s /usr/bin/screenkey --start-disabled crash_function: key_press exception_type: AttributeError executable: /usr/bin/screenkey interpreter: python3-3.9.7-1.fc34.x86_64 kernel: 5.13.19-200.fc34.x86_64 runlevel: N 5 type: Python3 uid: 1000 Truncated backtrace: labelmanager.py:319:key_press:AttributeError: 'NoneType' object has no attribute 'decode' Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/Screenkey/inputlistener.py", line 193, in _event_callback self.callback(data) File "/usr/lib/python3.9/site-packages/Screenkey/labelmanager.py", line 319, in key_press symbol = event.symbol.decode() AttributeError: 'NoneType' object has no attribute 'decode' Local variables in innermost frame: self: <Screenkey.labelmanager.LabelManager object at 0x7fb60c244d60> event: <Screenkey.inputlistener.KeyData object at 0x7fb60a2eb430>
Created attachment 1828806 [details] File: backtrace
Created attachment 1828807 [details] File: environ
Created attachment 1828808 [details] File: mountinfo
Created attachment 1828809 [details] File: namespaces
Created attachment 1828810 [details] File: open_fds
Reported upstream: https://gitlab.com/screenkey/screenkey/-/issues/159
Upstream asks: Any chance to get more details on what was done to make it crash? There's probably some odd keyboard or mouse event which is not handled correctly. Could you provide some background on which actions triggered this, or if you have any specific keyboard/mouse setup?
At that time I didn't do anything with the program. I keep it running in the background at all times, not showing keys. If the code in that still collects keystrokes it could of course be some interaction with my system. There isn't anything special, though, if the code only looks at keystrokes. I have all kinds of USB devices attached, some might also act as HIDs, but they shouldn't produce obscure data. Until this morning screenkey didn't show anything anymore and I think that I haven't changed anything since the crash. The reason is the "start_disabled" entry in the config file which I hoped would start the program in a mode where it is by default not in the "show keys" mode. That seems not to be the case. But that setting shouldn't have any effect which could cause the bug, could it? Because the program is running in the background it's really hard to get better information unless the program collects it itself. For python code this often means adding checks for the conditions explicitly. If you add something to that extend and the problem persists I can provide better information.
Thanks for the details. Upstream mentions that the newer versions are immune to this problem, yet the root cause is not identified (https://gitlab.com/screenkey/screenkey/-/issues/159#note_701242787). If you can, try to revert this commit https://gitlab.com/screenkey/screenkey/-/commit/99a8a365de0b3880165392a2ba12c3632bbdbd71 and reproduce the issue? I will try to build a version on copr with this patch reverted in the weekend, for easier testing.
(In reply to Rajeesh from comment #9) > If you can, try to revert this commit > https://gitlab.com/screenkey/screenkey/-/commit/ > 99a8a365de0b3880165392a2ba12c3632bbdbd71 and reproduce the issue? Do you really mean "revert"? The version I have installed (which is the latest officially released) does not have this extra check installed.
Ouch. I have missed to notice (or missed to update) the two new releases after 1.2. Would update to 1.4 this weekend; and we can check if the problem persists.
FEDORA-2021-a117f3b672 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a117f3b672
FEDORA-2021-a9f674059b has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a9f674059b
FEDORA-2021-24aa95b578 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-24aa95b578
FEDORA-EPEL-2021-d4829075fa has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4829075fa
FEDORA-2021-24aa95b578 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-24aa95b578` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-24aa95b578 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a9f674059b has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a9f674059b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a9f674059b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-d4829075fa has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-d4829075fa See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-a117f3b672 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a117f3b672` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a117f3b672 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-24aa95b578 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-a9f674059b has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-a117f3b672 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-d4829075fa has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.