For the first time, I’m having real difficulties with dt3.1.0 under Windows. The problem seems to have occurred after v708 and <=777
So it would be nice to know if it’s just me, or more general 
You’ll need to be way more specific, please.
Sure: dt crashes more or less at random while navigating around the lighttable, or the darkroom, or between images. But most frequently when trying to apply a style.
Just ran a fresh copy cloned directly from darktable-org/darktable,
3.1.0+769~g1ef4476cf
and same problem, crashed when attempting to apply a style.
Running Win 10 190318-1202
If anyone can tell me what was the most recent build they were able to run without crashes, that would help.
I’ve answered a bit on github, but I can give more hints here too.
3.1.0+769~g1ef4476cf - this is the current master, known by you to be bad.
v708 is known to not be affected but you don’t know the hash, so let’s do it by math 769-708=61 (so 61 commits ago). since my git revisions-fu is weak i’ll use bruteforce and see the last line in git log:
git log --oneline -61
this gives me:90611440b (might be different for you)
So now you start bisecting!
do it like this:
- make sure you are on latest master
- enter folowing commands:
git bisect start
git bisect bad
git bisect good 90611440b
- now rebuild darktable (with clean install dir etc) and test if you can replicate the problem. if you can, issue command
git bisect bad(without any commit hash) and if you can’t (so the version is good) - issuegit bisect good - repeat step 3 until git tells you exactly which commit caused problem.
whit that knowledge go to github issue and describe process you’ve taken + results of your bisect hunt
now it’s time to reset your git repo with: git bisect reset
And you’re done! this will be significantly faster than trying each commit by hand as it will perform binary search on troubling commits.
4 Likes
No I have the same problem, do let me know if you have the solution.
@Maria_Hernandez : Yes! Thank’s to Johnny’s bisect instructions I pinned it down to a specific commit, and Philippe did the hard work of finding the error in a malloc
It’s been working fine for a few days now…