Bug 746478

Summary: [abrt] geeqie-1.0-11.fc14: file_data_unref_debug: assertion failed: (fd->magick == 0x12345678)
Product: [Fedora] Fedora Reporter: Peter Hanecak <hany>
Component: geeqieAssignee: Michael Schwendt <bugs.michael>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: bugs.michael
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:7f59b9b08ff11a41a76818bdd93a696ac35c29dd
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-16 14:07:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace none

Description Peter Hanecak 2011-10-16 12:48:15 UTC 
abrt version: 1.1.18
architecture: x86_64
Attached file: backtrace, 12189 bytes
cmdline: geeqie
comment: I've copied images from my camera to the PC in shell. Then I started geeqie and jumped back to the shell. In the shell I started renaming the JPG pictures, also moved the RAW images to another directory and then switched back to geeqie. geeqie crashed whilte rename was still running.
component: geeqie
Attached file: coredump, 22904832 bytes
crash_function: file_data_unref_debug
executable: /usr/bin/geeqie
kernel: 2.6.35.14-97.fc14.x86_64
package: geeqie-1.0-11.fc14
rating: 4
reason: Process /usr/bin/geeqie was killed by signal 6 (SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1318768933
uid: 500

How to reproduce
-----
1. load some images from SD card to some directory
2. start geeqie and open that directory
3. start renaming and moving images in the directory
Comment 1 Peter Hanecak 2011-10-16 12:48:18 UTC 
Created attachment 528386 [details]
File: backtrace
Comment 2 Michael Schwendt 2011-10-16 14:07:47 UTC 
So, this is still around.

As mentioned before, it is not easily reproducible. One can rename/move/delete thousands of files with an external shell/tool, and Geeqie may survive that.

The crash due to the assertion just means that filelist_free() ran into already freed filedata or invalid/corrupted memory. It does not tell in which place the filedata was freed before due to refcounting spread throughout the code.

*** This bug has been marked as a duplicate of bug 655610 ***