Project

General

Profile

Bug #8880

OSX crash when trying to import photo or folder

Added by SKR Imaging over 5 years ago.

Status:
Fixed
Priority:
High
Assignee:
Category:
Buildsystem
Target version:
-
Start date:
08/22/2012
Due date:
% Done:

100%

Affected Version:
git development version
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

First time I started app, it crashed right away.

I relaunched app and got to the main screen but when I tried to import a folder, it crashed.

I even tried importing just an image but still crashed.

I attached crash log for the folder import crash.

dt-MacOSX-crash.txt Magnifier - plain text version of the rtf file already attached (74.8 KB) James C. McPherson, 08/22/2012 03:25 AM

crash.txt Magnifier - full backtrace on OS X (7.02 KB) Igor Kuzmin, 08/22/2012 12:49 PM

linuxcrash.txt Magnifier - linux backtrace (22.2 KB) Igor Kuzmin, 08/22/2012 01:09 PM


Related issues

Duplicated by darktable - Bug #8887: Experimental darktable .dmg build crashes on OS X 10.8 when importing or opening .CRW images for editing Duplicate 08/23/2012

History

#1 Updated by James C. McPherson over 5 years ago

The stack trace piece of interest is as follows:

========================================================================
Crashed Thread: 5

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
objc3090: garbage collection is OFF
  • error for object 0x7fff75026860: pointer being freed was not allocated

Thread 0:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8c805df2 _select + 10
1 libdarktable.dylib 0x000000010122e174 dt_cache_sleep_ms.constprop.11 + 36
2 libdarktable.dylib 0x000000010122ef60 dt_cache_read_get + 208
3 liblighttable.so 0x000000011678d219 expose_filemanager + 1817
4 libdarktable.dylib 0x00000001012cdbcb dt_view_manager_expose + 171
5 libdarktable.dylib 0x000000010127437a dt_control_expose + 666
6 libdarktable.dylib 0x00000001012ad19f expose + 47
7 libgtk-quartz-2.0.0.dylib 0x00000001003080af _gtk_marshal_BOOLEAN
_BOXED + 159
8 libgobject-2.0.0.dylib 0x0000000100140214 g_closure_invoke + 308
9 libgobject-2.0.0.dylib 0x000000010014f899 signal_emit_unlocked_R + 1641
10 libgobject-2.0.0.dylib 0x0000000100150a2d g_signal_emit_valist + 3069
11 libgobject-2.0.0.dylib 0x0000000100150f54 g_signal_emit + 116
12 libgtk-quartz-2.0.0.dylib 0x000000010041d76c gtk_widget_event_internal + 620
13 libgtk-quartz-2.0.0.dylib 0x0000000100305e29 gtk_main_do_event + 1401
14 libgdk-quartz-2.0.0.dylib 0x00000001001b1f7d _gdk_window_process_updates_recurse + 493
15 libgdk-quartz-2.0.0.dylib 0x00000001001b1ec4 _gdk_window_process_updates_recurse + 308
16 libgdk-quartz-2.0.0.dylib 0x00000001001be06d -[GdkQuartzView drawRect:] + 333
17 com.apple.AppKit 0x00007fff8a2eaa67 -[NSView _drawRect:clip:] + 3995
18 com.apple.AppKit 0x00007fff8a2e8719 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] + 3020
19 com.apple.AppKit 0x00007fff8a2e286f -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] + 4755
20 com.apple.AppKit 0x00007fff8a2db259 -[NSView displayIfNeeded] + 1528
21 libgdk-quartz-2.0.0.dylib 0x00000001001cbbd4 _gdk_windowing_after_process_all_updates + 116
22 libgdk-quartz-2.0.0.dylib 0x00000001001b24fe gdk_window_process_all_updates + 286
23 libgtk-quartz-2.0.0.dylib 0x0000000100285260 gtk_container_idle_sizer + 64
24 libgdk-quartz-2.0.0.dylib 0x0000000100192c15 gdk_threads_dispatch + 53
25 libglib-2.0.0.dylib 0x000000010003e688 g_main_context_dispatch + 328
26 libglib-2.0.0.dylib 0x000000010004025e g_main_context_iterate + 510
27 libglib-2.0.0.dylib 0x00000001000416af g_main_loop_run + 287
28 libgtk-quartz-2.0.0.dylib 0x00000001003055cf gtk_main + 191
29 libdarktable.dylib 0x00000001012ae053 dt_gui_gtk_run + 51
30 darktable-bin 0x000000010000af7c main + 44
31 darktable-bin 0x000000010000af2c start + 52

Thread 1:
0 libsystem_kernel.dylib 0x00007fff8c80467a mach_msg_trap + 10
1 libsystem_kernel.dylib 0x00007fff8c803d71 mach_msg + 73
2 com.apple.CoreFoundation 0x00007fff9076850c __CFRunLoopServiceMachPort + 188
3 com.apple.CoreFoundation 0x00007fff90770c74 __CFRunLoopRun + 1204
4 com.apple.CoreFoundation 0x00007fff90770486 CFRunLoopRunSpecific + 230
5 com.apple.CoreFoundation 0x00007fff9078019f CFRunLoopRun + 95
6 libusb-1.0.0.dylib 0x00000001009f5f21 event_thread_main + 561
7 libsystem_c.dylib 0x00007fff8c25c8bf _pthread_start + 335
8 libsystem_c.dylib 0x00007fff8c25fb75 thread_start + 13

Thread 2:: Dispatch queue: com.apple.libdispatch-manager
0 libsystem_kernel.dylib 0x00007fff8c8067e6 kevent + 10
1 libdispatch.dylib 0x00007fff8ee3f78a _dispatch_mgr_invoke + 923
2 libdispatch.dylib 0x00007fff8ee3e31a _dispatch_mgr_thread + 54

Thread 3:
0 libsystem_kernel.dylib 0x00007fff8c806192 __workq_kernreturn + 10
1 libsystem_c.dylib 0x00007fff8c25e594 _pthread_wqthread + 758
2 libsystem_c.dylib 0x00007fff8c25fb85 start_wqthread + 13

Thread 4:
0 libsystem_kernel.dylib 0x00007fff8c805bca __psynch_cvwait + 10
1 libsystem_c.dylib 0x00007fff8c260274 _pthread_cond_wait + 840
2 libdarktable.dylib 0x0000000101273f7a dt_control_work + 90
3 libsystem_c.dylib 0x00007fff8c25c8bf _pthread_start + 335
4 libsystem_c.dylib 0x00007fff8c25fb75 thread_start + 13

Thread 5 Crashed:
0 libsystem_kernel.dylib 0x00007fff8c805ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff8c25e7d2 pthread_kill + 95
2 libsystem_c.dylib 0x00007fff8c24fa7a abort + 143
3 libsystem_c.dylib 0x00007fff8c2ae84c free + 389
4 libdarktable.dylib 0x000000010123f047 dt_exif_read_data(dt_image_t*, Exiv2::ExifData&) + 10839
5 ? 0x000000012da10c88 0 + 5060496520
6 ?
0x000000012da101d0 0 + 5060493776
7 ??? 0x000000012d253480 0 + 5052380288 ========================================================================

So more correctly, the problem is a crash in dt_exif_read_data(), which according to the kernel was

  • error for object 0x7fff75026860: pointer being freed was not allocated

#3 Updated by James C. McPherson over 5 years ago

SKR Imaging: please update this bug with the following information:

#0 what is the output from darktable --version ?

#1 Is this a reproducible problem?
#2 If #1 is "yes" is it reproducible with all images you are trying to import, or just some images?
#3 Please provide a representative sample image which we can use as a test case

#4 What camera type are you importing images from?

#4 Updated by James C. McPherson over 5 years ago

Two further questions for the submitter:

#1 Are you adding any tags or metadata when you import each image? (and if so, what)
#2 Please attach a copy of your $HOME/.darktablerc file

#5 Updated by SKR Imaging over 5 years ago

Here are the updates as per request:

#0: Where to find output info?

#1 it happens with all my RAW files (DNG format)... they all work on Linux version of Darktable. I tried a JPG file and it loaded with no error but I want to use Darktable for RAW editing.

#4 camera used is a Canon Powershot A710is with modified CHDK firmware (had no issues with RAW files from this camera before)

not adding any tags or metadata during import.

Could not find the darktablerc file (enabled show hidden in finder yet still could not find it)

#6 Updated by SKR Imaging over 5 years ago

cannot attach sample through this site. gives an error that it is too large (9.3 MB) all my DNGs are that size.

Here is dropbox link to the sample file: http://dl.dropbox.com/u/12563241/CRW_9943.DNG

#7 Updated by Igor Kuzmin over 5 years ago

About version - disk image was built from current git master, so it's either 1.0+1270~gf265d6d or 1.0+1272~gd1e162a (there's no darktable code difference between them, though bundled libraries were rebuilt with different flags). Version can be seen in main darktable window in the top left corner.
About darktablerc, correct location is ~/.config/darktable/darktablerc

#8 Updated by Igor Kuzmin over 5 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

This file causes DT to crash both on OS X and Linux, though somewhat differently. On Linux darktable imported the image fine and proceeded to darkroom mode, showed garbled image and them crashed.

#9 Updated by Igor Kuzmin over 5 years ago

#10 Updated by Igor Kuzmin over 5 years ago

darkroom view is actually fine, only thumb is garbled. Also on Linux crash isn't instant all the time, sometimes I have to click somewhere.

#11 Updated by James C. McPherson over 5 years ago

Cannot reproduce this on Solaris with current git master and exiv2 v0.22. I see that the two confirmed crashes are using exiv2 v0.23, so I'm building that for Solaris and will see if that changes things.

#12 Updated by Igor Kuzmin over 5 years ago

  • Category set to Buildsystem
  • % Done changed from 10 to 50
  • Assignee set to Igor Kuzmin
  • Status changed from Confirmed to In Progress

Linux crashing with this image seem to be unrelated to OS X issue, so I will create a separate bug report for it.
Please try new disk image: https://github.com/downloads/darktable-org/darktable/darktable-1.0+1276~gc31ed3e.dmg
It fixes the crash on import of this image for me on OS X Mountain Lion.
I tracked down the problem to the fact that two libstdc++ libraries were being loaded on darktable start. GCC-4.6 (which is needed for OpenMP support) that I used to build darktable links to its own version of libstdc++ and system libraries use system libstdc++.

#13 Updated by Igor Kuzmin over 5 years ago

  • File deleted (darktable OSX crash import folder.rtf)

#14 Updated by Johannes Hanika over 5 years ago

seems to be an issue with the embedded thumbnail (some inconsistent width/height storage garbage?), a workaround is to switch to half size raw instead of embedded thumb in the preferences (will result in slower import though).

#15 Updated by Ville Kärjä over 5 years ago

I can confirm that the latest image produced (https://github.com/downloads/darktable-org/darktable/darktable-1.0+1276~gc31ed3e.dmg) fixed crashing issues for me too (running OS X 10.8.1 now)! Now importing of .CRW images works correctly and I can enter darkroom to edit them.

#16 Updated by James C. McPherson over 5 years ago

Igor Kuzmin wrote:
...

I tracked down the problem to the fact that two libstdc++ libraries were being loaded on darktable start. GCC-4.6 (which is needed for OpenMP support) that I used to build darktable links to its own version of libstdc++ and system libraries use system libstdc++.

Perhaps if you tried building darktable with some extra LDFLAGS you might be able to get past this crazy linking thing that Mac OSX and MacPorts indulge in.

To build on Solaris I have this set in my environment before I start the build.sh script:

LDFLAGS="-R/opt/darktable/lib:/usr/gcc/4.6/lib -L/opt/darktable/lib -L/usr/gcc/4.6/lib -lumem"

That forces the linker to look first at /opt/darktable/lib, then at /usr/gcc/4.6/lib and only after that will it look at system libraries.

#17 Updated by Igor Kuzmin over 5 years ago

  • % Done changed from 50 to 100
  • Status changed from In Progress to Fixed

I think this issue is resolved, so I'm marking this bug as fixed. Feel free to comment/reopen if I'm wrong.

Also available in: Atom PDF