Bug 700950

Summary: [abrt] darktable-0.8-8.fc14: Process /usr/bin/darktable was killed by signal 4 (SIGILL)
Product: [Fedora] Fedora Reporter: Mike Parker <mikethepsych>
Component: darktableAssignee: Edouard Bourguignon <madko>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 14CC: madko
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:d8cd8a154b0b7b303cf88bd5faa09fdbcffb13f6
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-23 19:56:11 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
More informative gdb backtrace none

Description Mike Parker 2011-04-29 21:39:08 UTC
abrt version: 1.1.18
architecture: x86_64
Attached file: backtrace, 20441 bytes
cmdline: darktable
component: darktable
Attached file: coredump, 93544448 bytes
executable: /usr/bin/darktable
kernel: 2.6.35.12-90.fc14.x86_64
package: darktable-0.8-8.fc14
rating: 3
reason: Process /usr/bin/darktable was killed by signal 4 (SIGILL)
release: Fedora release 14 (Laughlin)
time: 1304113004
uid: 500

How to reproduce
-----
Invoked darktable from either command line prompt or Applications -> Graphics menu

Comment 1 Mike Parker 2011-04-29 21:39:12 UTC
Created attachment 495870 [details]
File: backtrace

Comment 2 Edouard Bourguignon 2011-04-30 09:41:30 UTC
The backtrace seems completely different from your previous bug #700486

I will try to reproduce this bug. Have you clean all previous files from other darktable version like /home/Mike/.config/darktable/library.db before running darktable?

Comment 3 Mike Parker 2011-05-02 17:49:53 UTC
As suggested, I removed my old library.db. 

Issue still persists - I still see "darktable was killed by signal 4 (SIGILL)" in ABRT.

Not really able to comment on different backtrace. From a user perspective, both versions appear to exhibit identical behaviour when crashing....

FYI, I have my suspicions that the issue *may* be related to the 0.8-X version having a dependency on the newer libexiv2.so.10 whereas older versions of darktable used libexiv2.so.9. 

Since upgrading the libexiv2 package to bring in libexiv2.so.10, I've seen a bug in gthumb related to the Exiv2::Internal::TiffDirectory::doWrite function (bug #700518). It might be nothing/unrelated, but I thought I'd let you know.

Comment 4 Mike Parker 2011-05-07 08:20:46 UTC
Additional data:

Invoking darktable 0.8-8 from the command prompt sees the following returned to STDOUT/ERR:

sqlite3 error: /builddir/build/BUILD/darktable-0.8/src/common/collection.c:447, function dt_collection_update_query(): no such table: selected_images
sqlite3 error: /builddir/build/BUILD/darktable-0.8/src/common/collection.c:448, function dt_collection_update_query(): no such table: selected_images
sqlite3 error: /builddir/build/BUILD/darktable-0.8/src/common/collection.c:449, function dt_collection_update_query(): no such table: selected_images
[image_cache_read] failed to recover the cache from `/home/Mike/.cache/darktable/mipmaps'
Illegal instruction (core dumped)

Comment 5 Mike Parker 2011-05-19 18:46:16 UTC
Created attachment 499923 [details]
More informative gdb backtrace

Comment 6 Edouard Bourguignon 2011-05-23 14:22:18 UTC
*** Bug 700486 has been marked as a duplicate of this bug. ***

Comment 7 Edouard Bourguignon 2011-05-23 14:23:10 UTC
Hi Mike,

Could you try with http://koji.fedoraproject.org/koji/getfile?taskID=3087454&name=darktable-0.8-11.fc14.x86_64.rpm

Is it still crashing with SIGILL?

Comment 8 Mike Parker 2011-05-23 19:56:11 UTC
Edouard,

0.8-11 seems to have resolved the issue - I no longer see the SIGILL crash and darktable appears to function fine.

I'll let you close the bug with the appropriate status.

Many thanks,

Mike