abrt version: 1.1.13
Attached file: backtrace
cmdline: /usr/bin/geeqie --blank
comment: I was quickly browsing through pictures (JPG + CR2) on an 15MB/s SD-card.
reason: Process /usr/bin/geeqie was killed by signal 6 (SIGABRT)
release: Fedora release 13 (Goddard)
How to reproduce
1. I was quickly browsing through pictures (JPG + CR2) on an 15MB/s SD-card.
Created an attachment (id=446251)
*** Bug 639720 has been marked as a duplicate of this bug. ***
(In reply to comment #2)
> *** Bug 639720 has been marked as a duplicate of this bug. ***
> Can you provide a test-case? I don't have access to any Canon
> photo equipment. And it seems to be specific to .cr2 files.
I've uploaded a few files (*.crc+*.jpg) to http://mihlit.cz/bz/rh/632243
When it crashed for me last time (3 times in a row, until I changed viewer), it happened when browsing through these files, but I can't reproduce it now despite I did not update anything related.
I've just hit this bug (several times) again yesterday. I can reproduce it quite well now. The most important for reproducing is that files must be stored on SD card. When I browse through files on SD card (even quite fast one - class 10), geeqie crashes after 4th or 5th file(tried 6 times, and it always crashed). When browsing through the same files on hdd, it does not crash (tried at least ten times).
Perhaps you can record such a single crash-session in a terminal with "geeqie --debug=5"?
If the speed of the accessed storage medium matters, that could be evidence of a race condition. Some of the image loading is multi-threaded.
I still haven't found a way to reproduce it. Not with SD cards either.
The source code is full of refcounting for FileData objects.
The crash in this ticket is due to a file object in an EXIF file data cache being both a sidecar file (with a parent image) as well as having a list of sidecar files itself. That's illegal, afaiks. The unref'ing cannot cope with that (and hence a fatal assertion fails and aborts the program). That assertion is placed in a strange place as IMO it should have been put in a place where to check that the invalid condition would never occur. Only that could help with finding the code portions that create the crap. More reading of the source will be necessary.
Created attachment 482378 [details]
log : geeqie --debug=5
Seems it's not 100 % reproducible for me now, but still I needed only 3 attempts.
(In reply to comment #5)
> .... That assertion
> is placed in a strange place as IMO it should have been put in a place where to
> check that the invalid condition would never occur. Only that could help with
> finding the code portions that create the crap.
If you want you can add extra asserts or debug output and I will test it.
The debug output looks very useful. Thank you very much!
From what I can see, it stumbled upon case-insensitive file name comparison in conjunction with a fstat() on a case-insensitive file-system. As a result, it added a file "*.JPG" as its own sidecar ".jpg":
| filedata.c:718: file_data_unref: deleting '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.JPG',
| parent '/media/EOS_DIGITAL/DCIM/100CANON/IMG_3230.jpg'
| ERROR:filedata.c:676:file_data_free: assertion failed: (fd->sidecar_files == NULL)
Early in the log it creates a longer list of file name extensions: .JPg, .JpG, .Jpg, .Cr2, .cR2, and so on.
A work-around test build for F-14 is here:
The corresponding src.rpm is this:
Created attachment 482417 [details]
log : geeqie --debug=5 IMG_3223.CR2
Almost there :) I can no longer make it crash through browsing files on SD card. Unfortunately, there is a regression. When I start geeqie by opening ANY.JPG file, it works, but when I start it by opening ANY.CR2, it dost not start, just crashes immediately. Again, only on SD card. Backtrace is looks very similar:
ERROR:filedata.c:679:file_data_free: assertion failed: (fd->sidecar_files == NULL)
Created attachment 482418 [details]
backtrace of geeqie test1 package
geeqie-1.0-9.fc14 has been submitted as an update for Fedora 14.
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.