I can't redo this problem, how do you make the vertical sliders go over the top? Is this a recent problem?

See attached video!
This is from version svn_27480.

br: Seppo

Hi, I can't reproduce this on Mac OS X 10.5.8, revision 27530... Any Windows users ?

I tested this with old builds (r27312, r27333, r27386, r27407, r27449, 27467, r27480 and r27526) and found:
1. with builds r27312 - r27407 color sliders behaved oddly (reported earlier) see video "r27407_color_selection_problem.wmv"
2. behavior has changed between r27407 and r27449
3. newer versions all crashed similar.

I have the same problem.
Win32 r27584
MSVC++ and CMAKE non optimized
all build options left at defaults

Here is a detailed but short video:
http://www.burningtoken.com/temppp/bug.mp4

I have built Blender on two separate computers with the same results.

Can confirm the crash on Vista x32 (SVN 27640). Drag the vertical slider to top and it crashs every time.

Can confirm this as a crash bug on Windows XP SP3 using Blender r27653

Trying to adjust vertical value slider results in the RGB field values being filled in with INF(inite) numbers. There is no way to recover from this. The program crashes.

Thomas, or other windows users, can you get a backtrace for the crash? Would be very helpful. Thanks

here is the output from debug in MSVC++. this output is from a release version of blender because the debug version doesn't behave the same. See below for separate issue with debug build. this build was made with cmake and MSVC++ express.

The program '[804] blender.exe: Native' has exited with code -1073740791 (0xc0000409).


I built blender using python and scons to see if the result was the same. It was. Here is the ouput:

The program '[1208] blender.exe: Native' has exited with code -1073740791 (0xc0000409).


The debug build has a different bug. The bug is that when you click on the brightness slider (yes, the brightness slider, not alpha slider like the post says,) it goes all the way down to black unless you use the scroll wheel to bring it back up. No click and drag, in other words.
Since I can't get the debug version to crash, I don't have any output for you on that.


If there is a different debugging program you'd like me to use or a different technique, let me know. Hope this helps and isn't just a waste of time!

It may also be worth mentioning that the other color picker types work great. Only the default one has bugs.

From OllyDbg CPU thread log:

7C97D1B9 C507 LDS EAX,FWORD PTR DS:[EDI] ; Modification of segment register
7C97D1BB 0038 ADD BYTE PTR DS:[EAX],BH
7C97D1BD 0E PUSH CS
7C97D1BE 03BB 52534453 ADD EDI,DWORD PTR DS:[EBX+53445352]
7C97D1C4 DAF4 FIDIV ESP ; Illegal use of register
7C97D1C6 92 XCHG EAX,EDX
7C97D1C7 69B1 F406448D 78>IMUL ESI,DWORD PTR DS:[ECX+8D4406F4],6C9>
7C97D1D1 B5 D2 MOV CH,0D2
7C97D1D3 07 POP ES ; Modification of segment register
7C97D1D4 0200 ADD AL,BYTE PTR DS:[EAX]
7C97D1D6 0000 ADD BYTE PTR DS:[EAX],AL
7C97D1D8 6E OUTS DX,BYTE PTR ES:[EDI] ; I/O command
7C97D1D9 74 64 JE SHORT ntdll.7C97D23F
7C97D1DB 6C INS BYTE PTR ES:[EDI],DX ; I/O command
7C97D1DC 6C INS BYTE PTR ES:[EDI],DX ; I/O command
7C97D1DD 2E:70 64 JO SHORT ntdll.7C97D244 ; Superfluous prefix
7C97D1E0 6200 BOUND EAX,QWORD PTR DS:[EAX]
7C97D1E2 0000 ADD BYTE PTR DS:[EAX],AL

Thanks very much for the testing, still not too helpful though :/

I was hoping when I read that, that I might be able to trigger the bug too, by changing to a Release build, however here it works correctly with Release/RelWithDebInfo/Debug build types.. I remember hearing something before that Mac OS X initialised new variables to zero by default, where other OSes might just point to existing memory, until its manually initialised, so I've looked in the relevant code to try and find areas where that may cause problems, but so far I haven't found anything yet.

If anyone can get even just a source file and line number that it crashes on, that would be very helpful..

Fixed in r27860. Please check that the crash is gone.

Not however that the commit only fixes the crash, still you get crazy colors when dragging the slider up too much (up to infinite RGB values).

Don't know if this helps or not:
I still have the crash
r27861
Windows XP
Nvidia GeForce 8400GS 512mb

It seems to occur when you first put your mouse over the brightness setting, then it will move the slider automatically to one end or the other(white, black). Maybe the error has something to do with drawing... when the mouse goes over the brightness.

Matt, Elia, the problem is that the RNA button circle_picker and square_picker have array index -1. In ui_check_but when it calls ui_set_but_soft_range, ui_get_but_val will try to access the array at index -1.

I tested this on:
Build: 27839-Win-SuperOptimizedEverythingBuild
Date: Mar-29-10
Type: BF
Builder: loopduplicate
http://www.graphicall.org/builds/builds/showbuild.php?action=show&id=1305

and it worked!
No crash nor weird colors, only thing was when alpha slider reches the top, color sliders jumps into the midle positions (numerical values stayed at 1.00).
But that, I think, is all right since they can be adjusted to values > 1.00.

With latest build I can reach: "27841-Windows Simple Default Build", the buck is still there!
The slider is not moved by it self!
When one coler slider is first moved higher value then others, alpha slider is not going over the top. -> no crash!!!

Tested on Vista32.

Weird, Elia tried that and still said he was having problems.. Anyway I've committed that, and some other tweaks too.

Brecht, one thing that's odd is that ui_set_but_soft_range is getting called via:
ui_numedit_apply -> ui_apply_button -> ui_apply_but_VEC -> ui_check_but ->

even while dragging the slider, though I believe it should really only be called after the button's exited and deactivated (after stopping dragging) - hence the comment /* only update soft range while not editing */ . Not sure if this is causing the problem, but it is a little odd I thought.


Anyway - Question to the people reporting this issue:
Is this reproducible with the official 2.5a2 build from blender.org? Are the builds you are using with any kind of optimisations?

For me, all builds have been normal (not optimized any kind), exept that "27839-Win-SuperOptimizedEverythingBuild".
I download them from graphicall.org, and their type are usually "BF" (what ever it means).

Matt,

To answer both of your questions:
1) Is this reproducible with the official 2.5a2 build from blender.org?

In 2.5a2 there is a different bug. You are not able to crash blender by using the vertical brightness slider. If you enter values into the R G B fields that are very high, blender will accept them and you can get the color picker to crash blender in the exact same way. Is that clear? I can make a demo video if it's not.

2) Are the builds you are using with any kind of optimisations?

No. I do not report on optimized builds. I am testing this bug with a build I personally made with scons, making sure to clean the install before making a new build with the command: scons.py -c

For the record, this bug is the same if I use cmake with extra options and compile with MSVC++ Express alone.

-------------------

The recent commits have at least prevented the crash. I am using r27869.

This bug can be used as a random color picker, by the way, so a part of me will be sad to see it go!

Adding video for "27869-Windows Simple Default Build" color adjustment!

Hi all,

I can reproduce the bug mentioned in this report and have a fix available. The problem is that the line "hsv[2] = srgb_to_linearrgb(hsv[2]);" in the function ui_numedit_but_HSVCUBE() can actually result in hsv[2] being greater than 1.0(very, very slightly). This is definitely a precision issue since the input is clamped to a maximum of 1.0 and the calculations performed in srgb_to_linearrg() should not return values greater than 1.0.

I believe after the calculations are done, the UI subsystem attempts to set the slider's position based on these new values. The slider's range is 0.0 to 1.0 and attempts to set it to something outside this range is giving us the undefined behavior.

The patch I am submitting should clamp srgb_to_linearrg() so it won't exceed 1.0. The clamping is done within srgb_to_linearrg() since it seems like it is called in numerous areas. Peer review is highly recommended since I'm not sure whether or not this is the "ideal" solution.



Index: source/blender/blenlib/intern/math_color.c
===================================================================
--- source/blender/blenlib/intern/math_color.c (revision 28295)
+++ source/blender/blenlib/intern/math_color.c (working copy)
@@ -350,7 +350,9 @@
if (c < 0.04045f)
return (c < 0.0f)? 0.0f: c * (1.0f/12.92f);
else
- return powf((c + 0.055f)*(1.0f/1.055f), 2.4f);
+ {
+ return minf(1.0f, powf((c + 0.055f)*(1.0f/1.055f), 2.4f));
+ }
}

float linearrgb_to_srgb(float c)



On an unrelated note, is it intentional design that the user can manually type in RGB values far greater than 1.0?

Thanks a bunch for finding that, Charlie! Maybe it's some imprecision with powf on some platforms, windows builds using fast-math perhaps?

Your fix isn't the correct one though, it's perfectly possible for colours to be greater than 1 (it's floating point colour), however the dragged slider value should be kept within the allowed range.

Fix is in svn, glad to see this one go.