There were a lot of changes in 3.0, so in a way this isn’t that surprising. Sometimes you have to be persistent in your bug reports, make sure you’ve attached as much information as possible, and maybe even learn how to install GDB to get the backtrace. Also if the bug isn’t 100% reproducable, then it’ll be more difficult.
There isn’t much you can do except get more involved.
Just trying to be polite))) If no one’s interested, so be it… And yes, I understand that major rework DT is suffering now will lead to some (temporary) inconveniences. Just the amount of them was a surprise)))
It’s there already, specifically for DT. It also seems I’ve to enable core dump feature for that purpose (which I normally disable not to clutter the FS. Anyways, except DT a core dump is not a frequent case). However, if nobody reacts on the bug reports, it’s just a waste of time… or not? TBH currently I don’t feel it will be of any use, because most of my recent reports were orphaned. I quit programming some 25 years ago, and all I can really help with is reporting bugs and participate somehow in debugging by providing a relevant info. But nobody asks for it…
Most of them are as such, otherwise they’d be wiped out at early stages))) Which doesn’t mean they shall stay forever…
The real situation is even worse. A lot of bugs sit there quietly and show up only under some specific conditions, e.g. on specific graphic card… that may not be at dev’s disposal at all…
That’s the worst. It’s most likely either bad drivers or actually faulty core on card. I think whole slew amd cards require ROCm update since it “overoptimizes” some routines causing bad effects in one of modules.
Hey, I’m usually asking (ever since I started wanting to help more) 
Point me to your bugs and I keep them active 
The most annoying are these two, for starters. Others seem to be resolved or somehow cared now, or closed in favor of related issues, or of lesser importance.
Not mine, but I suffer from it, too. Didn’t know how to reopen it. My comment seems to be lost. (I also learned the lesson that I shall open separate bugs instead of commenting on other, even if it’s completely relevant to the discussion. Except for clear dupes of open bugs. Much higher possibility the comment will be lost in comparison with a separate bug report, even on active discussion).
Also, I’m suffering from segfaults on my last git build, but haven’t reported it yet. I need to rebuild the DT up-to-date to see if the issue is still there and enable core dump in fstab to catch the fault. Then I’ll be able to report it.
Thanks for getting involved!
I’ve also experienced the second issue - though when changing exposure via a dynamic shortcut rather than via the histogram. I’ve added a comment to the issue.
Well, the life seems to be getting better)))
Since this turned into a bit of “support thread” my advice to anyone building their darktable:
-Og is great 
I think i’ve seen couple reports on gcc that using -funroll-loops produces code that runs slower than expected etc 
additionally - if you compile with clang it may be also break-prone (more than gcc). So - specifying compiler and compiler flags in error reports coming from self-built darktable with custom flags and/or compiler is a must!
I noticed that -fipa-pta breaks latest DT code (there was my report on github). Up to 2.6.X (inclusive) it was fine with all the optimizations I use, rock solid. So I believe that DT shall build and work with all of optimizations as other 1000+ packages of my system do, and if it fails with optimizations, there is a bad code or a bug there, most probably some undefined behavior (-O3 just loves to manifest UBs). But as a temporary measure, sounds very reasonable. However I don’t think it’s related to OpenCL regression somehow))) BTW it’s quite fresh, v3.0 worked just fine.
@johnny-bit, saw your comment on github, will provide all the info you requested. Thanks again!
imho -O3 being not solid is a myth. RawTherapee uses -O3 since a while (some years) without issues.
-Ofast is bad …
My recommendation stands - If you have optimized flags, you should disable them if program is displaying weird behaviour. Enabling them step-by-steps allows developers to see which part of code might create problems and alter it.
There’s nothing wrong with -O3, nor with any other flag.
Personally I’ve the whole system built with LTO and -O3 for at least 4-5 years (-O3 came first, LTO as gcc was ready). BTW mesa is built with -O3 by default for years. The status oh the whole thing may be seen here GitHub - InBetweenNames/gentooLTO: A Gentoo Portage configuration for building with -O3, Graphite, and LTO optimizations
As I understand it, the order of modules in the history is irrelevant to the order applied in the pixelpipe. “Show only active modules button” shows the pixelpipe order with the lowest modules being the first to be applied (i.e. the one at the bottom “raw black/white point” is the first to be applied.
Yes the order in the history is unrelated to the order in the pixelpipe (which is displayed on the right-hand pane as you say). But if you discard all history, you will reset the module order to the current default, along with removing all of the editing history. It’s just a way to reset the image back to default settings.