Closed gpagnon closed 1 year ago
Not reproducible with integration test images (opencl with dedicated gpu or opencl disabled) So check with https://github.com/darktable-org/darktable-tests/blob/master/images/mire1.cr2 to exclude the dng as a cause. If the error further occurs you can run darktable with option —disable-opencl to exclude issues in OpenCL support. Gold standard is providing the dmg and xmp so it’s possible to try to reproduce it on different system configurations.
Hi Martin,
Thank you for your reply and suggestion. I did previously try to run dt with --disable-opencl (I forgot to mention it) and it still crashes. Same story if I use the latest 3.5.x you built and posted on pixls.us. However, it does NOT crash with the test image you linked to and with other images of mine (even from the same camera). I have noticed in the past that dt happens to crash on particular images, even though there seems to be no problem at all when processing them in Lightroom. So, to me it looks like there is some computation in some dt module that makes it crash when input with certain image values.
I understand that the bug may be difficult to track down. If it helps, I can certainly send the DNG image: should I just add it as an attachment?
thanks again giuseppe
On Wed, Mar 10, 2021 at 7:03 PM Martin Straeten notifications@github.com wrote:
Not reproducible with integration test images (opencl with dedicated gpu or opencl disabled) So check with https://github.com/darktable-org/darktable-tests/blob/master/images/mire1.cr2 to exclude the dng as a cause. If the error further occurs you can run darktable with option —disable-opencl to exclude issues in OpenCL support. Gold standard is providing the dmg and xmp so it’s possible to try to reproduce it on different system configurations.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/8457#issuecomment-795833457, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUJAIQJIHD5O5VOPDCWO6DTC6X5ZANCNFSM4Y533NSQ .
-- Giuseppe Pagnoni Dip. Scienze Biomediche, Metaboliche e Neuroscienze Sezione Fisiologia e Neuroscienze Univ. di Modena e Reggio Emilia Via Campi 287 I-41125 Modena, Italy Tel: +39-059-205-5742 Fax: +39-059-205-5363
You might run darktable from terminal with -d all options to see where exactly the crash occurs. If you provide the dmg i can try to reproduce it.
I'm also running into this issue. I can't reproduce it consistently with a specific set of steps but I have reliably crashed when moving around the filmicrgb
sliders. I don't run Darktable from the command line, but I did get a big process dump (attached below). The stack trace seems to point to a memory access or allocation issue (and looking at a couple other stack traces this seems to be consistent). I have noticed that it's somewhat reliably reproduced if I click around a bit or move things very quickly, so it could be related to multiple things working at the same time.
I'm also on macOS Big Sur, and on Late 2013 Retina MacBook Pro. My OpenCL is disabled and the OpenCL scheduling profile
is set to default in the settings.
I can also provide a raw DNG and XMP file if the stack trace isn't sufficient.
Hello Martin,
thanks for looking into this. I am attaching the output of "darktable -d all". The steps I do to make it crash (in the scene-referred workflow):
1) raise the Exposure 2) lower the Dynamic Range Scaling in the Filmic module to the left 3) Use the color picker in Color Calibration (CAT16) and then try to adjust the hue 3b) Also if I use the preset "Acros" in the Color Calibration, more often that not darktable crashes immediately after selecting the preset
I have noticed that dt crashes also with another file from the same camera: both files are quite dark, can this induce an error in the darktable pipeline?
I have tried to attach the DNG file but apparently it is over the size limits (> 13MB). I'd be happy to post it somewhere else, if it's useful.
cheers dt_log_1.txt
Since you have xcode installed you can try to find the origin of the crash by running darktable within the debugger: lldb /Applications/darktable.app/Contents/MacOS/darktable when the (lldb) prompt occurs type r to start. when crashing you get info where exactly the error occurred. Unless this is obvious for a developer they‘ll need the dmg to reproduce. You can provide this using a arbitrary file hosting service (e.g. ms onedrive, google drive, mega.nz, dropbox ...)
Hi Martin,
thanks for the debugger tip. I have actually stumbled upon an error when entering the commands you suggested in a terminal:
error: process exited with status -1 (attach failed (Not allowed to attach to process. Look in the console messages (Console.app), near the debugserver entries when the attached failed. The subsystem that denied the attach permission will likely have logged an informative message about why it was denied.))
At any rate, I have posted two problematic images on Google Drive ( https://drive.google.com/file/d/13oKCiz3xTYu1lI2C_0AqVz1-6G798IK7/view?usp=sharing, https://drive.google.com/file/d/1I65OirU1EsvhHJJWuYOEzMyi8Dp0QHxP/view?usp=sharing, https://drive.google.com/file/d/1KvqpRiXWzlbHh8Rq5seHvYvhT3ycSFmT/view?usp=sharing, https://drive.google.com/file/d/1X6V7P5A0Z3wemJ1AvQ9AXEN_69_JCYMb/view?usp=sharing ):
Thanks for your support best giuseppe
On Sun, Mar 14, 2021 at 10:10 AM Martin Straeten @.***> wrote:
Since you have xcode installed you can try to find the origin of the crash by running darktable within the debugger: lldb /Applications/darktable.app/Contents/MacOS/darktable when the (lldb) prompt occurs type r to start. when crashing you get info where exactly the error occurred. Unless this is obvious for a developer they‘ll need the dmg to reproduce. You can provide this using a arbitrary file hosting service (e.g. ms onedrive, google drive, mega.nz, dropbox ...)
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/darktable-org/darktable/issues/8457#issuecomment-798873555, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFUJAIUG2CQNCQWQE6MAVMTTDR4OVANCNFSM4Y533NSQ .
-- Giuseppe Pagnoni Dip. Scienze Biomediche, Metaboliche e Neuroscienze Sezione Fisiologia e Neuroscienze Univ. di Modena e Reggio Emilia Via Campi 287 I-41125 Modena, Italy Tel: +39-059-205-5742 Fax: +39-059-205-5363
with my current 3.5 build it's not reproducible (at least with my system configuration), but i get an Error:
[colorin] could not find requested profile `standard color matrix'!
[colorin] `Ricoh GR' color matrix not found!
so i did a build of 3.4.1 myself to be able to reproduce and got it:
libfilmicrgb.so was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 88729 stopped
* thread #155, stop reason = EXC_BAD_ACCESS (code=1, address=0x15987f008)
frame #0: 0x000000011d726827 libfilmicrgb.so`.omp_outlined..135 at filmicrgb.c:954:38 [opt]
951 = (HF_c[c] * gamma_comp + fminf(fabsf(HF_c[c] / grey_details), 1.f) * grey_texture) * beta;
952 // reconstruction
953 reconstructed[k + c] =
-> 954 fmaxf(reconstructed[k + c] + alpha * (delta * (grey_HF + color_details) + (grey_residual + color_residual) / (float)scales), 0.f);
955 }
956 }
957 }
Target 0: (darktable) stopped.
This line of code is changed in 3.5 - done with https://github.com/darktable-org/darktable/pull/7837
I am having a similar issue. (DT user for some years an not an issue before 3.4) Versions 3.4 and 3.4.1; not tested anything later. OS = High Sierra System = MacBook Pro late 2013 with 16Gb & 1Tb SSD using external EIZO monitor.
I get the following, with or without Open_CL enabled: (darktable:6378): GLib-GObject-WARNING **: 01:49:37.111: invalid cast from 'GtkMenuBar' to 'GtkWindow'
(darktable:6378): Gtk-CRITICAL **: 01:49:37.111: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
So initially, my question is what is the correct verion of the Gtk library for DT? Mine is Gtk version 3.24.14.
Further ...
However, crashes only seem to occur when Open_CL is enabled, I have tried various mixes of memory , GPU, CPU threads etc. and it all seems to come back to filmic. The instances of each fault are undefined (not intermittent but irregular), but once established they are reproducible. This might seem similar to hardware fault except that I do not get this elsewhere in other programs, so my only other thoughts were of a possible race condition.
The filmic module itself produces unreliable results if Open_Cl is enabled. Always manifesting itself in a jumbled image, either the main image or the navigation image and sometimes both. As long as I have filmic active in the pipeline stack I get this kind of result:-
If I export the image the image is OK.
Thanks for any assistance Regards Graham
the GTK messages are not related to the issue and even not critical - gtk and osx aren't best friends ;) OpenCL is dependent of your system configuration - not every GPU confguration is properly supported (esp. some intel gpu) You can check your opencl settings in darktablerc config file - that might explain why export is fine. in general filmic can work with opencl on osx - and since the opencl kernels are built on your machine at runtime (but cached) it might not be reproducible on different machines.
You might provide the xmp so it's possible to check if it's ok in different system configurations
Thanks Martin.
I'll look into some of the OpenCL settings and see if it changes anything. For the moment I have found that certain blend settings allow me to make adjustments, chroma is one. Normal will give the above result sometimes as soon as I enter the filmic module.
Unfortunately I accidentally moved the xmp file and now I get recurring message "history problem detected ..."
As a result I deleted the xmp file and since then everything has worked as expected, including ALL of the blend modes.
In case it matters: the original xmp file was generated in 2018. I was revisiting the photos with the latest darktable to try out some features one of which was filmic, after viewing the very enlightening explanations given by Aurélien PIERRE on youtube.
I will explore further and add my findings, along with any relevant docs.
Regards Graham
Here is an xmp file, as short as it needs to be. The first attempt at changing a module revealed the problem.
I have tried this with various sensors: D300s, D800, Z6, Z7, all with the same behaviour.
I should have added in the first post that the histogram also shows weird behaviour that i not representative of what I expect to see from a normal rendering of the image in the centre panel. It becomes very distorted and throws colours all over the place. A bit like a photo multiplier might behave from a non-continuous spectrum after being put through a randomiser.
After some experimenting it seems to be a rendering issue. At a guess, I think that an image is held in a buffer for working on and then that image is rendered both in the navigation panel and in the centre panel. The rendering stops when it think that rendering is complete, but it isn't. If I zoom in or out or move the illuminated part of the navigation image, the centre panel becomes rendered correctly - as I guess causing the image t be repainted and this time the image is rendered correctly. Checking the XMP file show no difference in content from before or after zooming.
Although I am currently using DT on High Sierra I have also installed Big Sur on a separate volume with Xcode, with a view to following this up. However, I would like some guidance for where to probe.
<?xml version="1.0" encoding="UTF-8"?>
This issue did not get any activity in the past 30 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
@glpix - can you attach xmp as .txt
file? it looks like it got trimmed badly by github.
also to @gpagnon and @glpix - do you still experience problems with current master?
This issue did not get any activity in the past 60 days and will be closed in 365 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.
This issue was closed because it has been stalled for 300 days with no activity. Please check if the newest release or nightly build has it fixed. Please, create a new issue if the issue is not fixed.
Darktable crashes when I try to follow a scene-referred workflow on a DNG (from a Ricoh GR) file. To reproduce: 1) Adjust Exposure 2) Open the filmic module and decrease with a mouse click the dynamic range scaling slider (often darktable crashes already here) 3) Open the Color calibration module, and use the color picker within the CAT16 adaptation; darktable often crashes here, but if not, it crashes when I try to adjust the slider below (hue)
In the terminal window from which I started darktable, I read:
~ % /Applications/darktable.app/Contents/MacOS/darktable
(process:19015): GLib-GObject-CRITICAL **: 12:28:59.332: g_object_set: assertion 'G_IS_OBJECT (object)' failed
(process:19015): Gtk-WARNING **: 12:28:59.400: Locale not supported by C library. Using the fallback 'C' locale. [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152
(darktable:19015): GLib-GObject-WARNING **: 12:29:03.535: invalid cast from 'GtkMenuBar' to 'GtkWindow'
(darktable:19015): Gtk-CRITICAL **: 12:29:03.536: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"... zsh: abort /Applications/darktable.app/Contents/MacOS/darktable
and the logfile that Mac OS X reports is attached.
darktable_log.txt
My system is a MacBook Pro 13", the last generation before M1, running Mac OS Big Sur 11.2.3 and Xcode 12.4. The darktable version is the following:
darktable --version this is darktable 3.4.1 copyright (c) 2009-2021 johannes hanika darktable-dev@lists.darktable.org
compile options: bit depth is 64 bit normal build SSE2 optimized codepath enabled OpenMP support enabled OpenCL support enabled Lua support enabled, API version 6.1.0 Colord support disabled gPhoto2 support enabled GraphicsMagick support enabled ImageMagick support disabled OpenEXR support enabled
Thanks for any suggestion, if you need any further information please ask (I am not quite expert in submitting bugs)