This isn’t new. This has been an issue for me for several versions of DT. It might even be slightly worse with 4.8, but that’s just an impression.
When I go to create a new duplicate inside the darkroom module, either with the ‘Duplicate’ or ‘Original’ button, DT is reasonably likely to crash either straight away or within a couple of seconds.
It’s sporadic. I can be making duplicates and merrily working on them for quite a number of sessions. But then suddenly, bang. Or it might happen in fairly rapid succession.
I hope you see below a report in .txt form of the Apple report manager.
I hope you guys can help with this, even though it has been persisting for several versions of DT. I honestly cannot recall in which version it first appeared, sorry.
I experience issues with the duplicate manager as well. Every other time when creating a duplicate, the option for selecting the module groups is frozen - clicking on the buttons doesn’t change anything. When selecting a module it opens up and I can make changes in the module but they are not reflected in the image.
I can echo this…never had this experience in any version of DT I have used and running on WIndows so I guess we can check the log…OP sounds like they are on an Apple version and I think there are a few unique problems to versions that run on that OS from time to time that don’t impact users on Linux or Windows…
A log would be what darktable outputs when done on a shell with debug options. Here we would likely need -d pipe -d opencl as a starting point for investigation.
I now have installed DT 4.8.0 on a new Mac laptop, and am having a weird variation on my problem with Duplicates that inspired me to open this topic.
Creating a Duplicate doesn’t cause DT to crash (so far), but I lose the ability to edit using the Develop modules. They are basically unresponsive. Not just for the image that I duplicated, but for ALL images. DT itself isn’t locked up: I can swap between Lighttable and Darktable. I can apply Styles to the image. But the Develop modules are locked/jammed/unresponsive.
Thanks. If a solution is found, eg the user is doing something wrong, does it get posted into the above GitHub thread?
Odd that the Darkroom processing modules lock out, but Styles still work, even though they apply the same processing modules.
I will try to learn how to run it “on a shell with debug options” as requested by Jens-Hanno above. I am one of many people using DT who are not computer-oriented ‘CLI types’, and we probably need a little more hand-holding than you guys are used to. I know it can be frustrating. But I assume the developers want it to be a friendly forum for ‘GUI types’ too, like me.
If a pull request with a bugfix has been merged (included into current master), this will close the issue report with a corresponding note. But first, a way must be found to reliably reproduce the bug. Then a developer has to pick up the issue and search for a solution.
That will probably be necessary. If you want to try it yourself, you would first have to update to 4.8.1. dt 4.8.0 contains a bug that has restricted the output of debug information.
Currently there is no description of what exactly causes the problem and how to reproduce it. It is also not clear whether it is really limited to MacOS. Furthermore, there is no bug log yet, and no second user has confirmed the problem. Even the poster of the issue report seems to have problems to reproduce…
OK I updated to 4.8.1 and after a bit of Develop processing and Duplicate creation, it locked into a semi-frozen “working…” situation. If I look in the Terminal window I see an infinitely scrolling screen of output. A snapshot of it as a screenshot looks like this:
Where do I find the report that you want me to post? Do I have to wait for DT to fully crash? Or is the report generated while it is in the above state?
You should be able to copy the entire contents of the terminal (event the scrolled-past older entries) into a simple text file, which you could then attach here.
An even simpler way is to add >darktable.log 2>&1 at the end of the command; that will already send the output to the log file (you won’t see anything in the terminal window).
I copied the entire contents of the Terminal, and here is the Terminal window output for about 30 minutes, at which point I Force Quit (MacOS) Darktable:-
(oops the text file is large, so I will put it on Google Drive and share it with a link):-
My understanding of this issue is that it causes dt to freeze (due to an infinite loop ?), making parts of the UI unresponsive.
That is the point. Nobody is going to analyze 161 MB of text, accumulated over 30 minutes, especially if it is not known when (time) the problem occurred.
So how could this be achieved?
First try to reproduce the problem reliably (without logging).
Try to find out exactly which steps are required to force the freeze. For example, is there a specific image with a specific history stack that leads to the problem ?
Describe these steps as precisely as possible, only then there is a chance that someone can reproduce
After a restart (with logging), use exactly these steps to trigger the problem as quickly as possible.
As soon as dt freezes, force quit dt (if necessary).
Using debug option -d common might be appropriate at first
A reasonably analyzable size of a log file is up to 500 kB to 1 MB.
Since there is already an issue report on github (see link above), all this should be continued there.
