Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[2.1.7, 2.1.8, Git master] Plugin smartpause calls disable_safeeyes with unsupported signature, causing display of a backtrace #580

Closed
hartwork opened this issue Jun 8, 2024 · 9 comments · Fixed by #582
Labels

Comments

@hartwork
Copy link
Contributor

hartwork commented Jun 8, 2024

Describe the bug
I witnessed this backtrace at runtime:

Exception in thread WorkThread:
Traceback (most recent call last):
  File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.10/threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.10/site-packages/safeeyes/plugins/smartpause/plugin.py", line 197, in __start_idle_monitor
    disable_safeeyes(None, True)
TypeError: SafeEyes.__init__.<locals>.<lambda>() takes 1 positional argument but 2 were given

The suppose cause is that code…

self.context['api']['disable_safeeyes'] = lambda status: utility.execute_main_thread(
self.disable_safeeyes, status)

…only supports a single argument while…
def disable_safeeyes(self, status=None, is_resting = False):

…supports more.

Could be a regression from commit 903d407 .

CC @AdamPS

To Reproduce
Steps to reproduce the behavior:

  1. Install 2.1.8
  2. Run safeeyes from the terminal
  3. Wait a bit
  4. See the backtrace above

Expected behavior
No backtrace

Desktop (please complete the following information):

  • OS: Gentoo Linux
  • Desktop Env: XFCE
  • Version 2.1.8

Debug Log
n/a

Screenshots
n/a

@hartwork hartwork added the bug label Jun 8, 2024
@hartwork hartwork changed the title [2.1.8] Plugin smartpause calls disable_safeeyes with unsupported signature, causing display of a backtrace [2.1.7, 2.1.8, Git master] Plugin smartpause calls disable_safeeyes with unsupported signature, causing display of a backtrace Jun 8, 2024
@archisman-panigrahi
Copy link
Collaborator

archisman-panigrahi commented Jun 9, 2024

Is this issue present in releases with python 3.12? Or is it python version independent. For maximum stability, I am planning to only include the new version of safe eyes (2.1.8 or later) for Ubuntu 24.04 or later. For previous versions of Ubuntu, Safe Eyes is already available on the official repositories.

@archisman-panigrahi
Copy link
Collaborator

How to reproduce this crash?

@archisman-panigrahi
Copy link
Collaborator

I ran safeeyes in terminal in Kubuntu 24.04, and when I enable smartpause, safeeyes prints the following in the terminal, but it does not crash.

screen saver extension not supported

I am using KDE 5.27 with Wayland.

@deltragon
Copy link
Collaborator

Oh, I actually ran into this issue in #576 - the first commit there (7c241f1) contains a fix. I will pull it out into a separate PR today in the evening.

@deltragon
Copy link
Collaborator

I ran safeeyes in terminal in Kubuntu 24.04, and when I enable smartpause, safeeyes prints the following in the terminal, but it does not crash.

screen saver extension not supported

I am using KDE 5.27 with Wayland.

This needs to be tested on either GNOME or Sway Wayland, or on X11 - KDE Wayland currently does not support smartpause at all, really. (It uses xprintidle, which ends up always being idle, effectively.)
This is what I am trying to fix in #576.

(The message about screen saver not supported is unrelated, it's from the Do Not Disturb plugin.)

@hartwork
Copy link
Contributor Author

hartwork commented Jun 9, 2024

How to reproduce this crash?

@archisman-panigrahi quoting myself from above:

To Reproduce Steps to reproduce the behavior:

  1. Install 2.1.8

  2. Run safeeyes from the terminal

  3. Wait a bit

  4. See the backtrace above

The smartpause plug-in needs to be enabled of course. And I think not doing anything else in that time helps if the plugin wants to disable SafeEyes only when the machine is idle. My understanding of the plugin is superficial at the moment, though.

@hartwork
Copy link
Contributor Author

hartwork commented Jun 9, 2024

Oh, I actually ran into this issue in #576 - the first commit there (7c241f1) contains a fix. I will pull it out into a separate PR today in the evening.

@deltragon cool, thank you!

@deltragon
Copy link
Collaborator

I have a fix up in #582. It would be good if you could test it, and confirm it resolves the issue.

@AdamPS
Copy link
Collaborator

AdamPS commented Jun 25, 2024

Sorry for creating the problem and not responding earlier. I have only just found time to come back to safeeyes and I'm glad that someone has fixed it many thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants