geeqie icon indicating copy to clipboard operation
geeqie copied to clipboard

Geeqie exits when overwriting an image file being displayed

Open jefferysmall opened this issue 1 year ago • 36 comments

ISSUE TYPE

  • Bug Report

GEEQIE VERSION

99-> geeqie --version
Gtk-Message: 18:07:38.913: Failed to load module "xapp-gtk3-module"
Geeqie 2.1+git20231221-214be330 GTK3

This is the extracted current AppImage

OS / DISTRIBUTION

Xubuntu 22.04.3 LTS

SUMMARY

Geeqie is open and displaying one of a number of images in a directory -- a combination of Sony raw (arw) and jpg files. GIMP is being used to edit the jpg file being displayed. When the jpg is exported from GIMP and overwrites the existing file, sometimes this happens gracefully and then other times it causes Geeqie to immediately exit. There is no crash file produced.

I wonder if this is in some way related to bug #159

STEPS TO REPRODUCE

Export files from GIMP until it occurs.

jefferysmall avatar Dec 23 '23 02:12 jefferysmall

I suspect this happens when Edit/Preferences/General/Refresh On File Change is selected. This could be turned off, and a manual Refresh made at intervals. I know this does not solve the problem.

If this is the case, perhaps the realtime_monitor_cb() is seeing the change and unreffing the fd, while the same fd remains in vf->list. It might be the solution is to eliminate the assert() that causes the crash, and just ignore the error.

caclark avatar Dec 23 '23 13:12 caclark

I tried repeatedly saving an image that was not currently being displayed in Geeqie and no problems.

I tried your suggestion of disabling 'Refresh On File Change' and there were no exits/crashes. However, If I saved and quickly clicked on the refresh button while the save was still underway, then Geeqie crashed. The need for a manual refresh is a pain and I will revert to the previous version until this is addressed.

I just upgraded to this development version two days ago in order to (hopefully) address some other problems, and began to see this crashing problem. For reference,, this never occurred with version 1.7+git20220327-6d541232 GTK3

Thanks for looking into this.

jefferysmall avatar Dec 23 '23 21:12 jefferysmall

I am still unable to replicate this. The latest AppImages have the -Ddevel=enabled option set, which produces a (usually useful) stack dump when a crash occurs.

caclark avatar Feb 08 '24 12:02 caclark

OK, I'll download the most current AppImage and see what happens. If it does core dump will it be in the starting directory or elsewhere, and how should I get it to you?

jefferysmall avatar Feb 08 '24 15:02 jefferysmall

Tried it running 2.2+git20240207-5547f6ae (extracted AppImage) and it exited on the first attempt to save an image. Retried and same thing happened.

However, there is no dump file in the current directory, in /var/lib/apport/coredump or in /var/crash.

jefferysmall avatar Feb 08 '24 15:02 jefferysmall

Now using Geeqie 2.4+git20240624-f47c8f1a GTK3 (extracted AppImage) and I'm getting the same issue. When the thumbnail is active and the current JPG image is exported repeatedly from GIMP, geeqie core dumps. I got a core image in /var/lib/apport/coredump. here is some gdb info:

% file /usr/lbin/Geeqie-240624/AppRun /usr/lbin/Geeqie-240624/AppRun: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=86bc6644a3eca0daef30e3b0ec672a7eb121044f, not stripped

% gdb /usr/lbin/Geeqie-240624/AppRun /var/lib/apport/coredump/core* ... Reading symbols from /usr/lbin/Geeqie-240624/AppRun... (No debugging symbols found in /usr/lbin/Geeqie-240624/AppRun)

warning: Can't open file /SYSV00000000 (deleted) during file-backed mapping note processing

warning: core file may not match specified executable file. [New LWP 3869531] [New LWP 3869074] [New LWP 3869060] [New LWP 3869054] Core was generated by `/usr/local/bin/Geeqie-240624/usr/local/bin/geeqie --geometry=1852x2039+989+41 -'. Program terminated with signal SIGBUS, Bus error. #0 0x00007fb4132089fc in ?? () (gdb) bt #0 0x00007fb4132089fc in ?? () #1 0x0000000000000000 in ?? ()

Not very useful. Suggestions? I can upload the core file if it would be helpful.

jefferysmall avatar Jul 14 '24 17:07 jefferysmall

I tried:

% /usr/lbin/Geeqie-240624/AppRun -Ddevel=enabled .

But I get a pop-up that says:

Invalid parameter(s): -Ddevel=enabled This option is unknown

jefferysmall avatar Jul 14 '24 18:07 jefferysmall

Howdy. According to https://askubuntu.com/a/1231605, you can run an AppImage with --appimage-extract, which will hopefully extract a geeqie binary somewhere in there. Try using that binary with gdb and your core file.

That said, sometimes a Bus Error is a hardware issue of some sort.

xsdg avatar Jul 14 '24 21:07 xsdg

xsdg: That is exactly what I did and reported two comments ago. The AppRun is the extracted binary and the gdb output is what I got against the core file. It looks like this version of the AppImage may not have been compiled with the proper settings. And even thought the binary is not stripped, gdb cannot find any debugging symbols.

jefferysmall avatar Jul 14 '24 21:07 jefferysmall

Are you positive? Your gdb output shows: Core was generated by `/usr/local/bin/Geeqie-240624/usr/local/bin/geeqie --geometry=1852x2039+989+41 -'.

So I was expecting the geeqie binary to be either at that relative location, or in some other subdirectory. (That said, note that I have no experience with AppImages, so anything I say/infer could easily be wrong)

xsdg avatar Jul 14 '24 22:07 xsdg

You are correct. I assumed that /usr/lbin/Geeqie-240624//AppRun was the actual binary but it must exec /usr/lbin/Geeqie-240624/usr/local/bin/geeqie. I should have looked more closely at the preliminary info. Let's try again:

% gdb /usr/lbin/Geeqie-240624/usr/local/bin/geeqie /var/lib/apport/coredump/core._usr_local_bin_Geeqie-240624_usr_local_bin_geeqie.1000.7eba8768-e63b-41a1-89bc-debc2c3c5730.3869054.34085054

GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1 Copyright (C) 2022 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 "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: https://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.

For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lbin/Geeqie-240624/usr/local/bin/geeqie...

Warning: Can't open file /SYSV00000000 (deleted) during file-backed mapping note processing [New LWP 3869531] [New LWP 3869074] [New LWP 3869060] [New LWP 3869054]

warning: Could not load shared library symbols for lib64/ld-linux-x86-64.so.2. Do you need "set solib-search-path" or "set sysroot"?

warning: Loadable section ".note.gnu.build-id" outside of ELF segments in /usr/local/bin/Geeqie-240624/runtime/compat/lib/x86_64-linux-gnu/libc.so.6 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/local/bin/Geeqie-240624/usr/local/bin/geeqie --geometry=1852x2039+989+41 -'. Program terminated with signal SIGBUS, Bus error. #0 __pthread_kill_implementation (no_tid=0, signo=7, threadid=140411106801216) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. [Current thread is 1 (Thread 0x7fb40224b640 (LWP 3869531))]

(gdb) bt #0 __pthread_kill_implementation (no_tid=0, signo=7, threadid=140411106801216) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=7, threadid=140411106801216) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=140411106801216, signo=signo@entry=7) at ./nptl/pthread_kill.c:89 #3 0x00007fb4131b4476 in __GI_raise (sig=7) at ../sysdeps/posix/raise.c:26 #4 0x000055bb62e1e4ba in add_collection_list ( collection_list=, func=0x7fb402249910, menu=0x4) at ../src/menu.cc:438 #5 submenu_add_collections (menu=, menu_item=0x0, func=0x7fb402249910, data=) at ../src/menu.cc:466 #6 #7 0x00007fb413debbcf in jpeg_fill_bit_buffer () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8 #8 0x00007fb413ded97c in ?? () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8 #9 0x00007fb413dde076 in ?? () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8 #10 0x00007fb413de62c6 in jpeg_start_decompress () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8 #11 0x000055bb62e84f22 in bar_pane_gps_view_state_changed_cb ( view=, data=0x7fb402249c00) at ../src/bar-gps.cc:778 #12 0x000055bb62dee6a4 in image_loader_get_error (il=0x7fb402249910) at ../src/image-load.cc:1393 #13 0x000055bb62deef30 in (anonymous namespace)::ddsDecodeDXT3 ( width=320890832, height=1686872112, buffer=0x7ffc7230bfe0 "@\203\212d\273U") at ../src/image-load-dds.cc:281 #14 0x00007fb41475b714 in ?? () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x00007fb414758ab1 in ?? () from /usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x00007fb413206ac3 in start_thread (arg=) at ./nptl/pthread_create.c:442 #17 0x00007fb413298850 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

(gdb) q %

jefferysmall avatar Jul 14 '24 22:07 jefferysmall

@jefferysmall What file formats are present in the directory that Geeqie has open? (If you're willing to share a filename listing, that would be helpful, but it shouldn't be necessary). Also, which file type (or filename) did Geeqie have open when the crash happened?

It looks like frame [Edit: 13] is already on the wrong track (width and height aren't believable). After that, I wouldn't be surprised if we're in Undefined Behavior land (perhaps with a corrupt stack). In particular, we started off in the DDS image loader, and then bounced through bar-gps.cc to end up in libjpeg, even though the method in question (bar_pane_gps_view_state_changed_cb) doesn't seem to have any method calls other than gtk UI state updates. After that, we bounced through libjpeg to end up submenu_add_collections somehow, which also doesn't seem to make sense.

xsdg avatar Jul 15 '24 01:07 xsdg

The problem can be exhibited in any directory including one with a single JPG file. My directories usually include a combination of JPG and ARW (Sony Raw) files. Geeqie never has any problem opening up and displaying whatever files (including PDFs) are in the directory or displaying the selected image. It only has this problem when the files is being exported from GIMP. I tried placing a single file in a directory and then repeatedly and quickly touching it. Geeqie did not seem to have a problem with this, but it did crash when exporting from GIMP. One thing you might investigate is that when GIMP exports the file, it may be deleting or zeroing out the existing file when overwriting it and geeqie may be getting "lost" as the status of the file and thumbnail are updated.

Here is the listing from the directory that I was most recently working in. I happened to be saving "bronners_15.jpg" over and over as my test when geeqie crashes. I'm pretty sure this is a thumbnail problem since geeqie will not crash if any other thumbnail is selected while the export operation occurs. A directory listing and a screenshot of geeqie follow.

116-> ls -l total 1334028 -rw-r--r-- 1 jeff cjs 38704664 Oct 21 2023 bronners_01.arw -rw-r--r-- 1 jeff cjs 16732001 Jun 27 15:03 bronners_01.jpg -rw-r--r-- 1 jeff cjs 39391794 Oct 21 2023 bronners_02.arw -rw-r--r-- 1 jeff cjs 15512296 Jun 27 15:13 bronners_02.jpg -rw-r--r-- 1 jeff cjs 38410668 Oct 21 2023 bronners_03.arw -rw-r--r-- 1 jeff cjs 15227024 Jun 28 17:00 bronners_03.jpg -rw-r--r-- 1 jeff cjs 39121478 Oct 21 2023 bronners_04.arw -rw-r--r-- 1 jeff cjs 17869581 Jun 28 17:03 bronners_04.jpg -rw-r--r-- 1 jeff cjs 38140084 Oct 21 2023 bronners_05.arw -rw-r--r-- 1 jeff cjs 14375359 Jun 28 17:07 bronners_05.jpg -rw-r--r-- 1 jeff cjs 37419710 Jun 29 18:01 bronners_06.arw -rw-r--r-- 1 jeff cjs 11673451 Jun 29 18:01 bronners_06.jpg -rw-r--r-- 1 jeff cjs 38592578 Oct 21 2023 bronners_07.arw -rw-r--r-- 1 jeff cjs 14484413 Jun 29 17:55 bronners_07.jpg -rw-r--r-- 1 jeff cjs 39947182 Oct 21 2023 bronners_08.arw -rw-r--r-- 1 jeff cjs 18821506 Jun 29 18:01 bronners_08.jpg -rw-r--r-- 1 jeff cjs 39459374 Oct 21 2023 bronners_09.arw -rw-r--r-- 1 jeff cjs 17366964 Jun 29 18:06 bronners_09.jpg -rw-r--r-- 1 jeff cjs 39117896 Oct 21 2023 bronners_10.arw -rw-r--r-- 1 jeff cjs 17676717 Jun 29 18:10 bronners_10.jpg -rw-r--r-- 1 jeff cjs 39778950 Oct 21 2023 bronners_11.arw -rw-r--r-- 1 jeff cjs 20399288 Jun 30 22:03 bronners_11.jpg -rw-r--r-- 1 jeff cjs 36606358 Oct 21 2023 bronners_12.arw -rw-r--r-- 1 jeff cjs 10895436 Jun 30 22:09 bronners_12.jpg -rw-r--r-- 1 jeff cjs 38439916 Oct 21 2023 bronners_13.arw -rw-r--r-- 1 jeff cjs 14554244 Jul 13 20:01 bronners_13.jpg -rw-r--r-- 1 jeff cjs 37922748 Oct 21 2023 bronners_14.arw -rw-r--r-- 1 jeff cjs 12683282 Jul 13 20:05 bronners_14.jpg -rw-r--r-- 1 jeff cjs 37094742 Oct 21 2023 bronners_15.arw -rw-r--r-- 1 jeff cjs 10315937 Jul 14 11:12 bronners_15.jpg -rw-r--r-- 1 jeff cjs 37883250 Oct 21 2023 bronners_16.arw -rw-r--r-- 1 jeff cjs 9174955 Jul 14 16:22 bronners_16.jpg -rw-r--r-- 1 jeff cjs 38585528 Oct 21 2023 bronners_17.arw -rw-r--r-- 1 jeff cjs 11760884 Jul 14 16:25 bronners_17.jpg -rw-r--r-- 1 jeff cjs 38641462 Oct 21 2023 bronners_18.arw -rw-r--r-- 1 jeff cjs 11869423 Jul 14 16:30 bronners_18.jpg -rw-r--r-- 1 jeff cjs 38829932 Oct 21 2023 bronners_19.arw -rw-r--r-- 1 jeff cjs 12573830 Jul 14 16:35 bronners_19.jpg -rw-r--r-- 1 jeff cjs 39260562 Oct 21 2023 bronners_20.arw -rw-r--r-- 1 jeff cjs 13548118 May 23 12:02 bronners_20.jpg -rw-r--r-- 1 jeff cjs 38876960 Oct 21 2023 bronners_21.arw -rw-r--r-- 1 jeff cjs 12872378 May 23 12:02 bronners_21.jpg -rw-r--r-- 1 jeff cjs 38739862 Oct 21 2023 bronners_22.arw -rw-r--r-- 1 jeff cjs 12563042 May 23 12:02 bronners_22.jpg -rw-r--r-- 1 jeff cjs 38547174 Oct 21 2023 bronners_23.arw -rw-r--r-- 1 jeff cjs 12274102 May 23 12:02 bronners_23.jpg -rw-r--r-- 1 jeff cjs 38635340 Oct 21 2023 bronners_24.arw -rw-r--r-- 1 jeff cjs 12532377 May 23 12:02 bronners_24.jpg -rw-r--r-- 1 jeff cjs 38757902 Oct 21 2023 bronners_25.arw -rw-r--r-- 1 jeff cjs 12724199 May 23 12:02 bronners_25.jpg -rw-r--r-- 1 jeff cjs 38441502 Oct 21 2023 bronners_26.arw -rw-r--r-- 1 jeff cjs 12113650 May 23 12:02 bronners_26.jpg

Screenshot_2024-07-14_21-02-20

jefferysmall avatar Jul 15 '24 04:07 jefferysmall

Thanks for the extra info, and especially the screenshot! I'd be really curious if this continues to manifest with thumbnails disabled, or in "Images as List" mode rather than "Images as Icons".

Basically, it's obvious that there's a bug here, but given that there aren't other folks reporting this same issue, it feels like there must be something that's causing it to show up for you but not for most other people.

Do your pictures tend to have a GPS location embedded?

xsdg avatar Jul 15 '24 08:07 xsdg

It's also really peculiar that Geeqie is ending up in the DDS loader at all. The only codepath that leads to it is here:
https://github.com/BestImageViewer/geeqie/blob/eedf9f9db467b9eb3ce1ae90dc8ec9c30e252f7a/src/image-load.cc#L754

And some sample JPEGs and ARWs I have on my system don't start with the three magic bytes to actually trigger that loader

$hd /.../nx7_7876.arw | head -2
00000000  49 49 2a 00 08 00 00 00  12 00 fe 00 04 00 01 00  |II*.............|
00000010  00 00 01 00 00 00 03 01  03 00 01 00 00 00 06 00  |................|

$hd /.../xt5_6666.jpg  | head -2
00000000  ff d8 ff e1 ff bc 45 78  69 66 00 00 49 49 2a 00  |......Exif..II*.|
00000010  08 00 00 00 0d 00 0f 01  02 00 09 00 00 00 aa 00  |................|

So Colin's hypothesis about a refcounting bug seems more likely than anything to do with the partially-written contents of the files.

xsdg avatar Jul 15 '24 08:07 xsdg

One last debugging step: if you can replicate this while running Geeqie with --debug, that should give some indication of where the train might have started to go off the tracks.

xsdg avatar Jul 15 '24 09:07 xsdg

/usr/lbin/Geeqie-240624/AppRun

When using an AppImage, you should execute the .../squashfs-root/Apprun file. I get: file ~/bin/Geeqie-latest-x86_64-AppImage/squashfs-root/AppRun /home/cclark/bin/Geeqie-latest-x86_64-AppImage/squashfs-root/AppRun: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=86bc6644a3eca0daef30e3b0ec672a7eb121044f, not stripped

And: file ~/bin/Geeqie-latest-x86_64-AppImage/squashfs-root/usr/local/bin/geeqie /home/cclark/bin/Geeqie-latest-x86_64-AppImage/squashfs-root/usr/local/bin/geeqie: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e3e02a82c5b7d1f7620cacdc108673c3e42f0d24, for GNU/Linux 3.2.0, with debug_info, not stripped

Trying to execute the .../squashfs-root/usr/local/bin/geeqie file gives cannot execute: required file not found

For the last few issues of the AppImage, a stack-dump is automatically generated if you run the AppImage from the command line and there is a crash.

Would you please execute this (as yet un-registered) bug from a cold start to see if the stack-dumping is working OK?: File/New Collection Right-click on the Collection window and select Save Collection As In Save Collection As insert /tmp/xxxxx.txt Click Save

A stack-dump should be produced.

caclark avatar Jul 15 '24 14:07 caclark

xsdg:

I just tried this with the icon pane in "Images as List" mode and yes, it still crashed. My pictures do not contain GPS data.

jefferysmall avatar Jul 15 '24 22:07 jefferysmall

xsdg:

Here is the output from:

/usr/lbin/geeqie --debug --geometry=1852x2039+989+41 --disable-clutter .

This coredump resulted from repeatedly saving bronner_20.jpg.

z.txt

jefferysmall avatar Jul 15 '24 22:07 jefferysmall

caclark:

I renamed /usr/lbin/squashfs-root/ as /usr/lbin/Geeqie-240624/ so that it doesn't get overridden by the next AppImage extraction.

/usr/lbin/geeqie is just a symlink to /usr/lbin/squashfs-root/AppRun

So I am executing the proper program. I was previously confused, not realizing that the actual executable at ./usr/local/bin/geeqie was being execed, and I initially pointed gdb at the wrong source file. The coredump does in fact work as I show above. My second point of confusion was that I had long ago set ulimit -c to 0 by default. Once I reset it to unlimited in the shell from which I was launching geeqie, I got the expected core dump. So user error on this one, not a problem with the code. Sorry about that.

jefferysmall avatar Jul 15 '24 23:07 jefferysmall

What do you get for ls -l /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png?

Also, could you repeat this with --debug=2? It looks like there's some extra debug logging that exists specifically for thumbnail management.

In particular, the following pattern looks kind of peculiar, where Geeqie fails to load the thumbnail, tries to recreate it, and says that it succeeded, only to fail again later on. (Note that there are two threads, so messages are interleaved a bit):

thumb progress: 9 of 26
new image loader 0x5608ba55a1c0, bufsize=4096 idle_loop=1
exif read /u/jeff/.cache/thumbnails/large/77e6f99d1fd7a32ed8c9a8bba2711f66.png, sidecar: -
Thread pool num threads: 2
freeing image loader 0x5608ba8b76a0 bytes_read=105247
thumb image done: /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_19.jpg
            from: /u/jeff/.cache/thumbnails/large/77e6f99d1fd7a32ed8c9a8bba2711f66.png
thumb progress: 10 of 26
new image loader 0x5608ba55a0f0, bufsize=4096 idle_loop=1
exif read /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png, sidecar: -
freeing image loader 0x5608ba55a0f0 bytes_read=0
thumb broken, unlinking: /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png
new image loader 0x5608ba55a020, bufsize=4096 idle_loop=1
exif read /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_20.jpg, sidecar: -
Found embedded icc profile in jpeg
Thread pool num threads: 2
freeing image loader 0x5608ba55a1c0 bytes_read=105251
Using custom jpeg loader
thumb image done: /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_20.jpg
            from: /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_20.jpg
thumb saving: /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_20.jpg
       saved: /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png
thumb progress: 11 of 26
new image loader 0x5608ba8b7500, bufsize=4096 idle_loop=1
exif read /u/jeff/.cache/thumbnails/large/731890edbeee1cd55bb1703891d6a49b.png, sidecar: -
Thread pool num threads: 1
freeing image loader 0x5608ba55a020 bytes_read=12276803
thumb image done: /u/jeff/Pictures/alpha/Michigan/Bronners/bronners_21.jpg
            from: /u/jeff/.cache/thumbnails/large/731890edbeee1cd55bb1703891d6a49b.png
thumb progress: 12 of 26
…

Then farther down, right before the crash, the same thing happens again (and including the stack trace for @caclark; it's very similar to the one from the core dump above):

new image loader 0x5608ba8b76a0, bufsize=4096 idle_loop=1
exif read /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png, sidecar: -
freeing image loader 0x5608ba8b76a0 bytes_read=0
thumb broken, unlinking: /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png
new image loader 0x5608ba55a0f0, bufsize=4096 idle_loop=1
Thread pool num threads: 2
   16.801792 (+00001.271583) pixbuf renderer updated - started drawing 0x5608ba564180, img: 4672x7008
   16.801824 (+00000.000032) pixbuf renderer updated - started drawing 0x5608ba564180, img: 4672x7008
   16.965300 (+00000.163476) image done
Using custom jpeg loader
freeing image loader 0x5608ba8b75d0 bytes_read=12276803
   17.137141 (+00000.171841) image load completed "/u/jeff/Pictures/alpha/Michigan/Bronners/bronners_20.jpg" (current)
   17.137193 (+00000.000052) pixbuf renderer done 0x5608ba564180
Stack trace (most recent call last) in thread 879166:
#10   Object "/usr/local/bin/Geeqie-240624/runtime/compat/lib/x86_64-linux-gnu/libc.so.6", at 0x7fcbbe66684f, in 
#9    Object "/usr/local/bin/Geeqie-240624/runtime/compat/lib/x86_64-linux-gnu/libc.so.6", at 0x7fcbbe5d4ac2, in 
#8    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0", at 0x7fcbbfb28ab0, in 
#7    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0", at 0x7fcbbfb2b713, in 
#6    Source "/home/runner/work/geeqie/geeqie/build/../src/image-load-dds.cc:281", in <unknown>::ddsDecodeDXT3(uint width, uint height, unsigned char *buffer) [0x5608b787df2f]
#5    Source "/home/runner/work/geeqie/geeqie/build/../src/image-load.cc:1393", in image_loader_get_error(ImageLoader *il) [0x5608b787d6a3]
#4    Source "/home/runner/work/geeqie/geeqie/build/../src/bar-gps.cc:778", in bar_pane_gps_view_state_changed_cb(ChamplainView *view, GParamSpec *, *gpointer data) [0x5608b7913f21]
#3    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8", at 0x7fcbbf1b62c5, in jpeg_start_decompress
#2    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8", at 0x7fcbbf1ae075, in 
#1    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8", at 0x7fcbbf1bbd70, in 
#0    Object "/usr/local/bin/Geeqie-240624/usr/lib/x86_64-linux-gnu/libjpeg.so.8", at 0x7fcbbf1bbbcf, in jpeg_fill_bit_buffer
Bus error (Nonexisting physical address [0x7fcb9df79112])
Bus error(coredump)

xsdg avatar Jul 16 '24 01:07 xsdg

Here is output from:

/usr/lbin/geeqie --debug=2 --geometry=1852x2039+989+41 --disable-clutter . > geeqee_debug_02.txt 2>&1

geeqee_debug_02.txt

jefferysmall avatar Jul 16 '24 02:07 jefferysmall

101-> ls -l /u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png ls: cannot access '/u/jeff/.cache/thumbnails/large/b51625f865de914d91a62cf2c151e4e4.png': No such file or directory

jefferysmall avatar Jul 16 '24 02:07 jefferysmall

Thanks, that's super interesting! Unfortunately, it also looks like the debug write buffer isn't getting fully flushed before geeqie crashes, so the log is missing a bit of what's happening right before the crash.

Could you repeat the --debug=2 in a directory containing:

  1. bronners_20.jpg and bronners_20.arw
  2. Separately, with just bronners_20.jpg

Basically, keeping it to one image pair will limit how much extraneous debug info is printed. And independently, just the jpg because I'm curious if the sidecar mechanism (which associates raw files with their respective jpgs) might be related.

xsdg avatar Jul 16 '24 07:07 xsdg

Here is the debug output in a directory with two files: bronners_20.{arw,jpg}

geeqie_debug_03.txt

jefferysmall avatar Jul 16 '24 18:07 jefferysmall

Here is the debug output in a directory with one file: bronners_20.jpg

geeqie_debug_04.txt

jefferysmall avatar Jul 16 '24 18:07 jefferysmall

Could you repeat the single-file run with thumbnails disabled? (Right-click on the file list and un-check "Show thumbnails")

Also, just so I can better understand what I'm seeing, how many saves from gimp is it usually taking to trigger the crash in these runs? (Knowing if it's the first save versus if it took two or more would be the most helpful, even though an exact count would be extra handy)

xsdg avatar Jul 16 '24 18:07 xsdg

The only way to see the Show trumbnails option is to first select Images as List. This is what I tried previously and it crashed, but I'll repeat it here with the single JPG file. Here is what it looked like.

Screenshot_2024-07-16_11-58-34

Usually geeqie crashes after the second export, but sometimes it takes more. It is also more likely to happen of the exports are issues rapidly, although that is not always necessary. In this case I exported once. Waited until it had completed and geeqie had updated. Then exported a second time and geeqie crashed. Here is the output.

geeqie_debug_05.txt

jefferysmall avatar Jul 16 '24 19:07 jefferysmall

For information only - the latest (maybe since May) AppImage also appends the stack trace to /tmp/geeqie-crash.log.

caclark avatar Jul 18 '24 17:07 caclark

Speaking of AppImage, is there any way to be automatically notified when a new AppImage is generated and made available from the Homepage?

jefferysmall avatar Jul 18 '24 18:07 jefferysmall