Slideshow with shuffle on 2 photos seems to get stuck

[phillipberndt]

Slideshow with shuffle on 2 photos seems to get stuck

[phillipberndt]

With 2 photos, there's a 50% chance that the next cycle will start with the same image that has been viewed before, resulting in you seeing one of the images for 20 seconds instead of 10. Is that what you mean? Or is it really stuck as in "can not change to the other image at all"? If the latter, then I have not been able to reproduce this (yet).

[TommyFlowers]

Yeah it seems completely stuck. I will try to isolate a small use case later today. Thanks

Sent from Samsung Mobile

-------- Original message --------
From: Phillip Berndt [email protected]
Date: 15/09/2015 07:28 (GMT+00:00)
To: phillipberndt/pqiv [email protected]
Cc: TommyFlowers [email protected]
Subject: Re: [pqiv] Slideshow with shuffle on 2 photos seems to get stuck (#42)

With 2 photos, there's a 50% chance that the next cycle will start with the same image that has been viewed before, resulting in you seeing one of the images for 20 seconds instead of 10. Is that what you mean? Or is it really stuck as in "can not change to the other image at all"? If the latter, then I have not been able to reproduce this (yet).

—
Reply to this email directly or view it on GitHub.

[TommyFlowers]

I'm able to reproduce this quite easily. The following script highlights the issue.

After a few rotations, it seems to get permanently stuck on one image.

I'm running on a raspberry Pi2 - although I'm surprised if that is the issue.

The issue goes away if I remove --shuffle. Full screen mode also has the issue.

Also, strangely, if I switch windows (Alt-tab), the stuck pqiv seems to kick back into life and the slideshow restarts. Although a few iterations later it will stick again.

Is there any extra logging I can turn on (or debug statements I can add) that can help?

Many thanks

rm -rf ~/pqiv-test
mkdir ~/pqiv-test
cd ~/pqiv-test
wget http://www3.nd.edu/~networks/HumanDynamics_20Oct05/images/Einstein_1_JPEG.jpg
wget http://www3.nd.edu/~networks/HumanDynamics_20Oct05/images/Darwin_1_jpg.jpg
cd ..
ls -al ~/pqiv-test
pqiv -s -d 3.0 --shuffle ~/pqiv-test &

[phillipberndt]

Thanks, I see the issue now. Indeed, this regression was introduced with 1a1b528, the fix for #35. My latest commit should fix this.

[phillipberndt]

The build error should be fixed now. Does the fix for the original bug work for you?

[TommyFlowers]

That certainly fixes the regression Cheers!
I wonder it would be possible to spot that, on a new cycle, if the first image to be displayed is the current image, we just skip onto the next one.
This would prevent the occasional 2*duration pauses observed when using --shuffle.
I can submit a separate feature request?
Thanks

[TommyFlowers]

The previous issue that would cause the slideshow to stick after only a few seconds is certainly fixed.

However, I've noticed that if you run the above script for around 50 mins, pqiv will eventually seg fault.

Also, it seems the slideshow can still get stuck, but only after a long time. When I then try a keypress - say "s" for example it then crashes. This is only once the slideshow is "stuck". Otherwise, it responds fine to user input.

[phillipberndt]

That's bad news. Do you by any chance have gdb installed on your R Pi? If so, it would help very much if you could run (an unstripped) pqiv from within gdb: Start gdb --args pqiv --shuffle ..., in gdb r (+newline) starts the program. Once it crashes, run bt for a backtrace and finally q to quit, then paste the complete output starting from the segfault here.) I'll let it run on my PC overnight, hopefully it'll crash as well.

[I'm interested in the bt for a segfault without any interaction from your part; I have a pretty good idea why it can crash if you press a key, and a bt after the crash won't help. If you're familiar with gdb, then a watchpoint for current_file_node becomming NULL would do the trick probably.]

[TommyFlowers]

Sure no problem. Yes the pi's come with gdb already installed. I have the test running now. Will post back. Cheers

[TommyFlowers]

segv trace below. I tried setting a watch for current_file_node==0 but it didn't fire

[TommyFlowers]

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
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 "arm-linux-gnueabihf".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/pqiv...done.
(gdb) break image_loader_thread
Breakpoint 1 at 0x10374: file pqiv.c, line 1600.
(gdb) r
Starting program: /usr/bin/pqiv -f -s -d 5.0 --shuffle /home/pi/pqiv-test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".

** (pqiv:3957): WARNING **: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files

** (pqiv:3957): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

** (pqiv:3957): WARNING **: Can't load fallback CSS resource: Failed to import: The resource at '/org/gnome/adwaita/gtk-fallback.css' does not exist

(pqiv:3957): Gtk-WARNING **: Theme parsing error: gtk-dark.css:1:63: Failed to import: The resource at '/org/gnome/adwaita/gtk-main-dark.css' does not exist
[New Thread 0x75a9e300 (LWP 3960)]
[New Thread 0x7529e300 (LWP 3961)]
[Switching to Thread 0x7529e300 (LWP 3961)]

Breakpoint 1, image_loader_thread (user_data=0x0) at pqiv.c:1600
1600 gpointer image_loader_thread(gpointer user_data) {/{{{/
(gdb) watch current_file_node == NULL
No symbol "NULL" in current context.
(gdb) watch current_file_node == 0
Hardware watchpoint 2: current_file_node == 0
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x0000f7d8 in unload_image (node=) at pqiv.c:1750
#2 0x0000f838 in file_tree_free_helper (node=0x64c70) at pqiv.c:1134
#3 0x000156b8 in bostree_node_weak_unref (tree=, node=) at lib/bostree.c:408
#4 0x000103b0 in image_loader_thread (user_data=) at pqiv.c:1605
#5 0x76635f3c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#6 0x76635f3c in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) q

[phillipberndt]

Thanks. I've been able to produce a similar crash. (Setting -d .01 produces a crash quite rapidly.) The issue was related to the latest slideshow changes. I forgot to properly decrease a weak reference counter, and it eventually overflowed, resulting in an early free(), or, in your case, in multiple calls to free (I presume).

[phillipberndt]

Also, here's a commit to make sure that new cycles start with a different image.

[TommyFlowers]

Fix for crash looks spot on. And the extra feature looks good too. Many thanks!