holding down arrow key in slideshow causes deadlock
Submitted by Adam Dingle
Assigned to Eric Gregory
Link to original bug (#716024)
Description
---- Reported by adam@yorba.org 2010-03-03 10:07:00 -0800 ----
Original Redmine bug id: 1502
Original URL: http://redmine.yorba.org/issues/1502
Searchable id: yorba-bug-1502
Original author: Adam Dingle
Original description:
To see the problem, start Shotwell with at least a few dozen photos in the library and start a slideshow. Now hold down the right arrow key for several seconds. When you let go, you'll see that Shotwell is hung for 10 seconds or more: during this time the slideshow toolbar won't appear and you can't press Escape to exit the slideshow. The CPU meter shows that the CPU is pegged during this time.
In full-window view, I can hold down the left/right arrow keys to zoom through my photos at a rate of several per second - this is convenient. It would be convenient if holding down the arrow keys behaved similarly in the slideshow. In any case, we shouldn't hang.
Related issues:
- duplicated by shotwell - 3882: Hang in fullscreen (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:47:00 -0700 ----
History
Comment 1
Updated by Jim Nelson over 3 years ago
- Status changed from Open to Review
- Assignee changed from Anonymous to Jim Nelson
Comment 2
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 3
Updated by Adam Dingle over 3 years ago
- Priority set to High
Comment 4
Updated by Adam Dingle over 3 years ago
- Assignee changed from Jim Nelson to Anonymous
Comment 5
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Comment 6
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
- Priority set to High
This bug has now worsened: if I hold down the arrow key in a slideshow, Shotwell hangs without consuming CPU, apparently deadlocked and never to return. We should fix this for 0.10.
#3535has been marked as a duplicate of this bug.
Comment 7
Updated by Adam Dingle over 2 years ago
- Subject changed from holding down arrow key in slideshow hangs Shotwell for a while to holding down arrow key in slideshow causes deadlock
Comment 8
Updated by Clinton Rogers over 2 years ago
What seems to be happening is that job.wait_for_completion() in PixbufCache.fetch() never returns after too many fetch requests stack up. We can manually force the issue to some degree by calling job.execute() before job.wait_for_completion(), but that still leaves us with the previous 'temporarily freeze and eat lots of CPU time' behavior (it eventually recovers and shapes up again).
I propose two changes:
Manually call job.execute() before job.wait_for_completion() as outlined above (this is supposed to happen already, but it seems to not happen to pending jobs if there are too many)
Insert a wait into SlideShowPage.on_previous() andSlideShowPage.on_next() such that if less than, say, half a second has elapsed since on_next() or on_previous() ran, we just return.
The former ensures that we actually get around to trying to grab the pixbufs in the first place, and the latter gives it time to happen, and both are very low-risk changes, far away from the 'core' of the app.
I'll turn in a diff shortly.
Comment 9
Updated by Clinton Rogers over 2 years ago
Proposed patch submitted via email.
Comment 10
Updated by Clinton Rogers over 2 years ago
- Assignee changed from Anonymous to Clinton Rogers
This has to be fixed before we can address the minimum slideshow duration.
Comment 11
Updated by Clinton Rogers over 2 years ago
It looks like if there's too much going on, we can get to a place where the PixbufCache has asked for a fetch to be queued and is waiting for it to finish, but it never makes it as far as the queue in the first place.
Comment 12
Updated by Adam Dingle over 2 years ago
- Assignee changed from Clinton Rogers to Lucas Beeler
Clinton, thanks for the preliminary investigation. Lucas and I discussed and he's going to look into this more deeply.
Comment 13
Updated by Adam Dingle over 2 years ago
- Assignee changed from Lucas Beeler to Anonymous
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 14
Updated by Adam Dingle over 2 years ago
- Target version set to 0.11
- Priority changed from High to Urgent
As reported at https://bugs.launchpad.net/ubuntu/source/shotwell/bug/812158 , this hang also occurs if the user presses the left arrow immediately after initiating a slideshow.
Would sure be nice to fix this for 0.11.
Comment 15
Updated by Lucas Beeler over 2 years ago
- Assignee changed from Anonymous to Eric Gregory
Comment 16
Updated by Eric Gregory over 2 years ago
- Description updated (diff)
- Status changed from Open to Review
Comment 17
Updated by Eric Gregory over 2 years ago
- Status changed from Review to 5
Fixed in 68b09bca
This eliminates a deadlock in BackgroundJob and moves the next/previous controls into SinglePhotoPage along with the hacky fix we have for when the user holds down the next/prev key.
This does uncover two more issues, which I've filed tickets for:
The hacky fix is entirely time-dependent. On a slow enough computer it won't work. Ticket #3892 (closed)
Slideshow transitions shouldn't be occurring when I use next/prev. It should just jump to the next photo asap. Ticket #3891 (closed)
Comment 18
Updated by rom1v - over 2 years ago
It still happens in shotwell 0.10.1.
In diaporama (F5), if I click several times on "right key" not to fast, it works. If I speed up and press "right key" for example 5 times per seconds, I have a deadlock, I have to "kill -2 $(pidof shotwell)".
Comment 19
Updated by Adam Dingle over 2 years ago
That's right: this bug was present in 0.10.1. We've fixed this in git master and so the fix will be present in the upcoming Shotwell 0.11.
Comment 20
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:44 UTC ---
This bug was previously known as bug 1502 at http://redmine.yorba.org/show_bug.cgi?id=1502
Unknown Component Using default product and component set in Parameters Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.11
Resolution: RESOLVED FIXED