Bug 632243 - [abrt] geeqie-1.0-2.fc13: ERROR:filedata.c:676:file_data_free: assertion failed: (fd->sidecar_files == NULL)
Summary: [abrt] geeqie-1.0-2.fc13: ERROR:filedata.c:676:file_data_free: assertion fail...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: geeqie
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Extras Quality Assurance
URL: https://sourceforge.net/tracker/?func...
Whiteboard: abrt_hash:469a1938c5cca3ebfc6bf628533...
: 639720 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-09 13:49 UTC by Egon Kastelijn
Modified: 2011-03-13 21:19 UTC (History)
2 users (show)

Fixed In Version: geeqie-1.0-9.fc14
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-13 21:19:39 UTC


Attachments (Terms of Use)
File: backtrace (21.82 KB, text/plain)
2010-09-09 13:50 UTC, Egon Kastelijn
no flags Details
log : geeqie --debug=5 (108.26 KB, text/plain)
2011-03-04 21:18 UTC, Michal Hlavinka
no flags Details
log : geeqie --debug=5 IMG_3223.CR2 (26.21 KB, text/plain)
2011-03-05 08:04 UTC, Michal Hlavinka
no flags Details
backtrace of geeqie test1 package (18.48 KB, text/plain)
2011-03-05 08:05 UTC, Michal Hlavinka
no flags Details

Description Egon Kastelijn 2010-09-09 13:49:59 UTC
abrt version: 1.1.13
architecture: x86_64
Attached file: backtrace
cmdline: /usr/bin/geeqie --blank
comment: I was quickly browsing through pictures (JPG + CR2) on an 15MB/s SD-card.
component: geeqie
crash_function: raise
executable: /usr/bin/geeqie
kernel: 2.6.34.6-47.fc13.x86_64
package: geeqie-1.0-2.fc13
rating: 4
reason: Process /usr/bin/geeqie was killed by signal 6 (SIGABRT)
release: Fedora release 13 (Goddard)
time: 1284039385
uid: 500

How to reproduce
-----
1. I was quickly browsing through pictures (JPG + CR2) on an 15MB/s SD-card.
2.
3.

Comment 1 Egon Kastelijn 2010-09-09 13:50:01 UTC
Created an attachment (id=446251)
File: backtrace

Comment 2 Michael Schwendt 2010-10-03 16:27:33 UTC
*** Bug 639720 has been marked as a duplicate of this bug. ***

Comment 3 Michal Hlavinka 2010-10-08 07:05:06 UTC
(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.

Comment 4 Michal Hlavinka 2011-03-04 09:06:52 UTC
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).

Comment 5 Michael Schwendt 2011-03-04 19:19:00 UTC
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.

Comment 6 Michal Hlavinka 2011-03-04 21:18:54 UTC
Created attachment 482378 [details]
log : geeqie --debug=5

Seems it's not 100 % reproducible for me now, but still I needed only 3 attempts.

Comment 7 Michal Hlavinka 2011-03-04 21:21:28 UTC
(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.

Comment 8 Michael Schwendt 2011-03-04 22:50:19 UTC
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

Comment 9 Michal Hlavinka 2011-03-05 08:04:38 UTC
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)

Comment 10 Michal Hlavinka 2011-03-05 08:05:41 UTC
Created attachment 482418 [details]
backtrace of geeqie test1 package

Comment 11 Fedora Update System 2011-03-05 10:44:31 UTC
geeqie-1.0-9.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/geeqie-1.0-9.fc14

Comment 12 Fedora Update System 2011-03-05 23:02:12 UTC
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

Comment 13 Fedora Update System 2011-03-13 21:19:21 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.