Kamujin's picture

Input Exceptions under 64bit Windows

I have noticed a number of exceptions when I build my projects with Platform Target = Any CPU and run them under Vista x64. If I change the Platform Target to x86, the exceptions are not triggered. It seems the problem may be related to the sign bit getting moved around improperly during type conversions.

The following exception occurs when I release the shift key (right or left) on my macBookPro.

System.OverflowException occurred
Message="Arithmetic operation resulted in an overflow."
Source="mscorlib"
StackTrace:
at System.IntPtr.op_Explicit(IntPtr value)
at OpenTK.Platform.Windows.WMInput.WndProc(Message& msg) in C:\...\OpenTK\Source\OpenTK\Platform\Windows\WMInput.cs:line 147

The following exception occurs when I spin the mouse wheel backward. Small moves backward do not trigger the exception.

System.OverflowException occurred
Message="Arithmetic operation resulted in an overflow."
Source="mscorlib"
StackTrace:
at System.IntPtr.ToInt32()
at OpenTK.Platform.Windows.WMInput.WndProc(Message& msg) in C:\...\OpenTK\Source\OpenTK\Platform\Windows\WMInput.cs:line 83


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

Is this OpenTK 0.9.0 or 0.9.1? I seem to remember this was a bug in the former that was resolved in the latter.

Kamujin's picture

I use the version from the SVN. I can wait until you put out a milestone release and retest.

the Fiddler's picture

Should be fixed now, can you please test again?

Kamujin's picture

***removed***

the Fiddler's picture

Can you please check whether the problem is fixed in revision 1380?

Kamujin's picture

As of Rev 1380, I am still seeing the problem. The inconsistency that I reported earlier was due to 1 version being forced to JIT to 32 bit arch. With both JITing 64bit arch, I see the problem in both. It's important to note that I don't get the error for small moves backwards, only large ones.

System.OverflowException occurred
Message="Arithmetic operation resulted in an overflow."
Source="mscorlib"
StackTrace:
at System.IntPtr.ToInt32()
at OpenTK.Platform.Windows.WMInput.WndProc(Message& msg) in C:\...\OpenTK\Source\OpenTK\Platform\Windows\WMInput.cs:line 83
InnerException:

msg = {msg=0x20a (WM_MOUSEWHEEL) hwnd=0x408a8 wparam=0xff100000 lparam=0x11602cf result=0x0}

                    mouse.Wheel += (msg.WParam.ToInt32() >> 16) / 120;

It looks like the problem down casting the wparam value to an Int32.

It turns out the keyboard problem is there still also.

System.OverflowException occurred
Message="Arithmetic operation resulted in an overflow."
Source="mscorlib"
StackTrace:
at System.IntPtr.ToInt32()
at OpenTK.Platform.Windows.WMInput.WndProc(Message& msg) in C:\...\OpenTK\Source\OpenTK\Platform\Windows\WMInput.cs:line 147
InnerException:

msg = {msg=0x101 (WM_KEYUP) hwnd=0x2167a wparam=0x10 lparam=0xc0360001 result=0x0}

                                if (((msg.LParam.ToInt32() >> 16) & 0xFF) == ShiftRightScanCode)
the Fiddler's picture

Thanks for the extra information, this should be fixed for real now by using UIntPtr instead of IntPtr to avoid overflows (rev 1381). My x64 virtual machine doesn't support mouse wheels, so please test that to see if it works alright.

Kamujin's picture

1381 seems to have fixed the problem with the keyboard, but it breaks all mouse wheel back events (even small ones).

System.OverflowException occurred
Message="Arithmetic operation resulted in an overflow."
Source="mscorlib"
StackTrace:
at System.UIntPtr.ToUInt32()
at OpenTK.Platform.Windows.WMInput.WndProc(Message& msg) in C:\...\OpenTK\Platform\Windows\WMInput.cs:line 91
InnerException:

msg = {msg=0x20a (WM_MOUSEWHEEL) hwnd=0x50afa wparam=0xffffffffff880000 lparam=0xb002b3 result=0x0}

wparam = 18446744073701687296

                    mouse.Wheel += (int)(wparam.ToUInt32() >> 16) / 120;
Inertia's picture

maybe the problem is related to the hardcoded mouse wheel delta?

the Fiddler's picture

No, that's not it (this is standard code in all libraries, e.g. Allegro, GLFW etc). The problem is caused by the ToUInt32() call. I still cannot use the mouse wheel on my test environment. Kamujin can you please check whether the following line fixes the issue? If not, the only solution is to cast to ulong (and take the associated speed hit on x32 systems.

unchecked
{
    mouse.Wheel += ((int)msg.WParam >> 16) / 120;
}