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

Crash in hamster-window-server: 'NoneType' object has no attribute 'set_cursor' #571

Closed
matthijskooijman opened this issue Feb 25, 2020 · 4 comments · Fixed by #572
Closed

Comments

@matthijskooijman
Copy link
Member

I was running the latest code, and Gnome showed me a crash report. Looking inside, I found that hamster threw an exception:

org.gnome.Hamster.WindowServer[9261]: Traceback (most recent call last):
org.gnome.Hamster.WindowServer[9261]:   File "/usr/lib/python3/dist-packages/hamster/lib/graphics.py", line 2136, in __on_mouse_move
org.gnome.Hamster.WindowServer[9261]:     self.__check_mouse(event.x, event.y)
org.gnome.Hamster.WindowServer[9261]:   File "/usr/lib/python3/dist-packages/hamster/lib/graphics.py", line 2094, in __check_mouse
org.gnome.Hamster.WindowServer[9261]:     self._window.set_cursor(gdk.Cursor(cursor))
org.gnome.Hamster.WindowServer[9261]: AttributeError: 'NoneType' object has no attribute 'set_cursor'

This happened when I was editing a running activity (IIRC I changed the title). I think I just pressed "enter" to confirm the edit (after the crash, hamster-windows-service was resarted and the edit was applied).

I know this is not so much to go on, but I wanted to at least record the backtrace somewhere. Maybe this helps someone to find the problem (or maybe others seeing the same can add more info).

This happened running commit 7138d1a, so effectively 3.0.

@ederag
Copy link
Collaborator

ederag commented Feb 25, 2020

Thanks for reporting.
Just to be sure, the issue arises when editing a specific fact from the gnome-shell-extension,
that opens the "Edit activity window", then changing something and hitting enter ?
I did not manage to reproduce from d-feet.
No obvious bug in the code at first sight. Need to follow from the stack trace upward to get a hint.
if self._windows: would fix it locally, but let's try to find out the root cause first.

It would be good to gather more information indeed, if that happens again.

@ederag
Copy link
Collaborator

ederag commented Feb 26, 2020

Found out part (if not all) of the explanation.
Despite appearances, following the code, it can't be a "close" issue at all.
Actually the _window is stored too late after the Scene instanciation.
A motion-notify-event (mouse move) happened before the do_draw is entered.

self._window = self.get_window()

The _window should be stored when realize is emitted. I'll test and file a PR.

@matthijskooijman
Copy link
Member Author

Sounds plausible. Your PR also sounds consistent with your implementation, though I have no GTK experience to really contribute a proper review. Thanks for picking this up, though :-)

@ederag
Copy link
Collaborator

ederag commented Mar 1, 2020

Thanks for the feedback !

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

Successfully merging a pull request may close this issue.

2 participants