abrt version: 1.1.13 architecture: x86_64 Attached file: backtrace cmdline: geeqie component: geeqie crash_function: raise executable: /usr/bin/geeqie kernel: 2.6.35.6-48.fc14.x86_64 package: geeqie-1.0-4.fc14 rating: 4 reason: Process /usr/bin/geeqie was killed by signal 6 (SIGABRT) release: Fedora release 14 (Laughlin) time: 1290381804 uid: 500 How to reproduce ----- 1. removed a few images in bash 2. observed geeqie crash when auto-refreshing directory
Created attachment 461888 [details] File: backtrace
> How to reproduce Unfortunately, it's very hard to reproduce. I know it's been like that since its predecessor GQview and certainly up to and including Geeqie 1.0 alpha. It'll need somebody to review and (likely) redesign the entire directory/file loading.
It could be that a related fix to handling of sidecar files (bug 632243) that also affects crashes in FileData reference counting also fixes this. Test update following shortly...
geeqie-1.0-9.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/geeqie-1.0-9.fc14
geeqie-1.0-9.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update geeqie'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/geeqie-1.0-9.fc14
geeqie-1.0-9.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 696297 has been marked as a duplicate of this bug. ***
What file types are involved here? File grouping enabled/disabled? What sorting in the file list?
file types involved: .jpg and .cr2 ~/.geeqie/geeqierc: metadata.sync_grouped_files: true file_sort.method: 1 file_sort.ascending: true file_sort.case_sensitive: false
Thanks. So, JPG+CR2 again. I don't know how difficult it is for you to reproduce the crash, but please download and update to this test-build (preferably including the -debuginfo pkg): http://koji.fedoraproject.org/koji/taskinfo?taskID=3001653 It's a scratch-build and available for a limited number of days. It would be interesting to hear whether that build still crashes in the same way.
I took a source RPM of the updated geeqie package as the x86_64 one requires libexiv2.so.10 (I can get that too from Koji) but that would break quite a lot of other packages I have installed. So ... I rebuild the sopurce RPM and installed that. Result: I redid hopefully same stuff as when the crash occured previously. This time without problem.
The new libexiv2 is because of a planned upgrade for F-14 that requires lots of rebuilds including geeqie: https://admin.fedoraproject.org/updates/search/exiv2 The new exiv2 is tagged into the koji buildroot for F-14, so all needed updates can be prepared, but that hasn't been trouble-free as can be read at above ticket in the Fedora Updates System "bodhi".
*** Bug 701008 has been marked as a duplicate of this bug. ***
Assuming that the geeqie-1.0-10.fc14 update has helped here, because there haven't been any dupes since then.
[reopening since this is the original backtrace and the link to the upstream ticket]
*** Bug 746478 has been marked as a duplicate of this bug. ***
For anyone who can simulate personal usage patterns to reproduce this, the full output of "geeqie --debug=255" for the crash might be interesting.
geeqie-1.0-13.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/geeqie-1.0-13.fc14
geeqie-1.0-13.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.