Project

General

Profile

Bug #12391

add_preset: Assertion `len == sizeof(dt_iop_colorbalance_params_t)' failed

Added by Helmut Jarausch 9 months ago. Updated 9 months ago.

Status:
Fixed
Priority:
Low
Assignee:
Category:
-
Target version:
Start date:
11/04/2018
Due date:
% Done:

100%

Affected Version:
git master branch
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Since a few days (or maybe two weeks) the GIT version of darktable fails on start up with
darktable: /var/tmp/portage/media-gfx/darktable-9999/work/darktable-9999/src/iop/colorbalance.c:209: add_preset:
Assertion `len == sizeof(dt_iop_colorbalance_params_t)' failed.

Is this a known bug, and is there a workaround?

Associated revisions

Revision 812be46a
Added by Pascal Obry 9 months ago

colorbalance: fix revert log profile (last instance) preset.

Fixes #12391.

History

#1 Updated by Aurélien PIERRE 9 months ago

No, you are the first one :-) I suspect a problem with your database version regarding the blending options. Could you try on a new database ?

#2 Updated by Helmut Jarausch 9 months ago

Aurélien PIERRE wrote:

No, you are the first one :-) I suspect a problem with your database version regarding the blending options. Could you try on a new database ?

Which database?

I think there is a real bug:

Looking at the definition of dt_iop_colorbalance_params_t one can see that is has length 64 (definitely an even number!)
But in colorbalance.c there is
void init_presets(dt_iop_module_so_t *self) {
// these blobs were exported as dtstyle and copied from there:
add_preset(self, _("revert log profile (last instance)"),
"010000000000803f0000803f0000803f0000803f0100003f0000803f0000803f0000803f0000803f0000803f0000803f0000803f0000803f86eb513f000090",
...
Note that is is a hex coding of a string of 63 bytes only.
Compare this with the second call to add_preset :
add_preset(self, _("split-toning teal-orange (2nd instance)"),
"010000009a99593f9eef833fea9d803feee4763f0000803f86b4873fc3c86f3f1867803f9a99993f443d803f2a41823f26037b3f6666663f0000803f00009041",
...

So is there a missing "41" at the end of the string in the first call?

#3 Updated by Pascal Obry 9 months ago

  • % Done changed from 0 to 100
  • Assignee set to Pascal Obry
  • Status changed from New to Fixed

Should be fixed! I do not compile with assertion activated, so I did not see this issue.

Also available in: Atom PDF