GNOME Bugzilla – Bug 769195
Shotwell event viewer/browser ceases to work
Last modified: 2018-03-05 17:49:08 UTC
When browsing events, the shotwell event browser ceases to function and does not display anything anymore. How to reproduce: - click on "All Events" - start scrolling downward (either by mouse or page down key) - somewhere in the middle, the browser window will go blank and cease to display anything. - from this point onwards, clicking on "All Events" will have no effect and just display an empty window with no events in it. - restarting the application recovers from this situation until repeating the above steps. I have roughly 4500 pictures in my library, imported from an iPhoto folder.
I cannot reproduce with my library here. Can you please provide a shotwell.log with SHOTWELL_LOG=1 ?
Created attachment 335796 [details] Shotwell Debug Log
Created attachment 335797 [details] Shotwell output to stderr I guess there's not much to see in the shotwell.log, But what's interesting is that once the bug hits, there is a ton of Gtk-WARNING messages about out of memory on stderr (see attachment). My ulimits are as follows: % ulimit -a -t: cpu time (seconds) unlimited -f: file size (blocks) unlimited -d: data seg size (kbytes) unlimited -s: stack size (kbytes) 8192 -c: core file size (blocks) unlimited -m: resident set size (kbytes) unlimited -u: processes 79363 -n: file descriptors 1024 -l: locked-in-memory size (kbytes) 64 -v: address space (kbytes) unlimited -x: file locks unlimited -i: pending signals 79363 -q: bytes in POSIX msg queues 819200 -e: max nice 0 -r: max rt priority 0 -N 15: unlimited I tried raising the stack size to unlimited, but it did not help. If it is of any help, I can provide an strace output as well.
Are you comfortable with valgrind?
Created attachment 335816 [details] output of valgrind --leak-check=full --log-file=shotwell.valgrind shotwell Never used it before. I'm attaching a log output. Tell me if you want me to use specific options.
Created attachment 335818 [details] [review] Work around missing GValue free Can you check the patch?
Created attachment 335852 [details] valgrind --leak-check=full --log-file=shotwell.valgrind /usr/local/bin/shotwell The patch did not fix the problem. I compiled shotwell from 0.23.7 source tar ball and applied the patch. Event browser crashes as before. I'm attaching another valgrind output.
ok, those were the obvious leaks. Can you try with --leak-check=full --show-leak-kinds=all And also a massif run? valgrind --tool=massif
Created attachment 335907 [details] valgrind --leak-check=full --show-leak-kinds=all --log-file=shotwell.valgrind /usr/local/bin/shotwell
Created attachment 335908 [details] valgrind --leak-check=full --show-leak-kinds=all --log-file=shotwell.valgrind /usr/local/bin/shotwell
Created attachment 335909 [details] valgrind --tool=massif /usr/local/bin/shotwell
mhm. Memory usage looks stable. There's a rather large chunk of thumbnail cache. What's your overall system memory?
% free total used free shared buff/cache available Mem: 20425948 5916316 4963952 2026112 9545680 12027092 Swap: 10223612 0 10223612
Ah. That error means cairo failed to allocate memory. _maybe_ 4k images make checkerboardlayout so ginormous that cairo bails out. Can you recompile with make VALAFLAGS="--define=TRACE_REFLOW --define=TRACE_REFLOW_ITEMS" and attach the debug log from running with that? That should show the sizes CheckerboardLayout requests
Created attachment 339106 [details] valgrind --leak-check=full --show-leak-kinds=all --log-file=shotwell.valgrind /usr/local/bin/shotwell
Created attachment 339107 [details] valgrind --tool=massif /usr/local/bin/shotwell
I meant just the shotwell.log from ~/.cache/shotwell, sorry.
Created attachment 339132 [details] shotwell.log
Is that with the error occuring? I can't see any reflow logs there.
Yes, that's with the error. I compiled with: make VALAFLAGS="--define=TRACE_REFLOW --define=TRACE_REFLOW_ITEMS" Do I have to add specific arguments to configure as well?
Did it run the Vala compiler? If not, can you remove the shotwell_vala.stamp file and re-run make?
Created attachment 339349 [details] shotwell.log Looks like the .stamp files were not removed by 'make clean', sorry. I removed them and this time the vala compiler seemed to run. At least the shotwell.log is a hell of a lot bigger. :-)
*** This bug has been marked as a duplicate of bug 786702 ***