Bug 632243
| Summary: | [abrt] geeqie-1.0-2.fc13: ERROR:filedata.c:676:file_data_free: assertion failed: (fd->sidecar_files == NULL) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Egon Kastelijn <redhat2> | ||||||||||
| Component: | geeqie | Assignee: | Michael Schwendt <bugs.michael> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 13 | CC: | bugs.michael, mhlavink | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | x86_64 | ||||||||||||
| OS: | Linux | ||||||||||||
| URL: | https://sourceforge.net/tracker/?func=detail&aid=3072615&group_id=222125&atid=1054680 | ||||||||||||
| Whiteboard: | abrt_hash:469a1938c5cca3ebfc6bf628533b7cdb015d0302 | ||||||||||||
| Fixed In Version: | geeqie-1.0-9.fc14 | Doc Type: | Bug Fix | ||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2011-03-13 21:19:39 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Egon Kastelijn
2010-09-09 13:49:59 UTC
Created an attachment (id=446251) File: backtrace *** 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: http://koji.fedoraproject.org/koji/taskinfo?taskID=2886214 The corresponding src.rpm is this: http://mschwendt.fedorapeople.org/geeqie-1.0-8.fc14.test1.src.rpm 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. 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. |