Bug 746478 - [abrt] geeqie-1.0-11.fc14: file_data_unref_debug: assertion failed: (fd->magick == 0x12345678)
Summary: [abrt] geeqie-1.0-11.fc14: file_data_unref_debug: assertion failed: (fd->magi...
Keywords:
Status: CLOSED DUPLICATE of bug 655610
Alias: None
Product: Fedora
Classification: Fedora
Component: geeqie
Version: 14
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Schwendt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:7f59b9b08ff11a41a76818bdd93...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-16 12:48 UTC by Peter Hanecak
Modified: 2011-10-16 14:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-16 14:07:47 UTC
Type: ---


Attachments (Terms of Use)
File: backtrace (11.90 KB, text/plain)
2011-10-16 12:48 UTC, Peter Hanecak
no flags Details

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 ***


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