WineHQ upgrade breaking dinput8:dinput?
This is a truly weird one. dinput8:dinput start failing on the 17th, the day after WineHQ was upgraded: https://test.winehq.org/data/tests/dinput8:dinput.html What makes this weird is that: * There has been no change to these tests between bd332f53f2d7 and 966a07149a02. In fact the last patch goes back to 2013. So it's not a bad patch. * The failures happen on every 32 bit test environment, from XP to Windows 10, VM or not, TestBot or not. Only 64 bit is spared. * I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue. The official WineTest binaries are build on WineHQ so I suspect the MinGW upgrade is somehow responsible for the new failures. However I don't know if the old compiler was masking them, of if the new one is causing them. Any ideas? For reference: * Debian Testing (my environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 * Debian 7 (close to former WineHQ environment): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.9.1 -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
On 03/23/2016 12:17 PM, Francois Gouget wrote:
This is a truly weird one. dinput8:dinput start failing on the 17th, the day after WineHQ was upgraded: https://test.winehq.org/data/tests/dinput8:dinput.html
What makes this weird is that: * There has been no change to these tests between bd332f53f2d7 and 966a07149a02. In fact the last patch goes back to 2013. So it's not a bad patch.
* The failures happen on every 32 bit test environment, from XP to Windows 10, VM or not, TestBot or not. Only 64 bit is spared.
* I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue.
The official WineTest binaries are build on WineHQ so I suspect the MinGW upgrade is somehow responsible for the new failures.
Well, it wasn't just a version upgrade but a change from mingw to the mingw-w64 fork. Afaik those two diverged quite a bit. bye michael
On Wed, 23 Mar 2016, Francois Gouget wrote: [...]
* I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue.
Recompiling the crosstest with -O0 gets rid of the failures: - bd332f53 -O0 dinput8:dinput test https://testbot.winehq.org/JobDetails.pl?Key=21616 So it does look like a compiler issue. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
It looks like usp10:usp10 is impacted too, but only for 64 bit builds, and only since the 18th instead of the 17th which is strange. Still compiling with -O0 instead of -O2 seems to fix the new failures: * 329dfee70c35 -O2 usp10:usp10 test 1 to 10 failures on Vista-Win8 in test.winehq.org, 1 here https://testbot.winehq.org/JobDetails.pl?Key=21620 * 329dfee70c35 -O0 usp10:usp10 test 0 failures https://testbot.winehq.org/JobDetails.pl?Key=21621 * bd332f53f2d7 -O2 usp10:usp10 test 0 failures on Vista-Win8 in test.winehq.org, 1 here https://testbot.winehq.org/JobDetails.pl?Key=21622 * bd332f53f2d7 -O0 usp10:usp10 test 0 failures https://testbot.winehq.org/JobDetails.pl?Key=21623 The last victim is wininet:url but only on some Windows XP VMs. Again compiling the test with -O0 fixes the failures. https://test.winehq.org/data/tests/wininet:url.html As far as I can tell these are the only tests that still have issues following the upgrade. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
Hello, Am 23.03.2016 um 14:05 schrieb Francois Gouget:
On Wed, 23 Mar 2016, Francois Gouget wrote: [...]
* I compiled a dinput8_crosstest.exe binary bd332f53f2d7 which was not failing according to the test.winehq.org results. But all I got is failures: - 887b445bb878, 8th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21611 - bd332f53f2d7, 16th, 0 test.winehq.org failures, 13 here: https://testbot.winehq.org/JobDetails.pl?Key=21610 - 329dfee70c35, 22nd, 13 test.winehq.org failures, 13 here https://testbot.winehq.org/JobDetails.pl?Key=21609 My MinGW compiler is more recent than the one WineHQ was using before the upgrade however. So I think this points to a compiler-related issue.
Recompiling the crosstest with -O0 gets rid of the failures: - bd332f53 -O0 dinput8:dinput test https://testbot.winehq.org/JobDetails.pl?Key=21616
So it does look like a compiler issue.
one point that could be related is the usage of function local static variables. When all of these got the "static" removed, I do not get the failures anymore. However I could not prove this with testbot as an empty patch did also succeed. Kind regards, Bernhard https://testbot.winehq.org/JobDetails.pl?Key=21671 https://testbot.winehq.org/JobDetails.pl?Key=21672 My local versions: - package gcc-mingw-w64-i686 4.9.1-19+14.3 - Debian Jessie 8.3.
On Fri, 25 Mar 2016, Bernhard Übelacker wrote: [...]
one point that could be related is the usage of function local static variables. When all of these got the "static" removed, I do not get the failures anymore. However I could not prove this with testbot as an empty patch did also succeed.
The TestBot's build machine is still on Debian 7 (though it should be upgraded at some point). That would explain the difference. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
On Fri, 25 Mar 2016, Francois Gouget wrote: On Fri, 25 Mar 2016, Bernhard Übelacker wrote: [...]
one point that could be related is the usage of function local static variables. When all of these got the "static" removed, I do not get the failures anymore. However I could not prove this with testbot as an empty patch did also succeed.
I have not found static directives that I could remove to fix the dinput8 failures. Which test did it make a difference for? Could you send a diff? All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's Makefile.in but that does seem like a nice workaround :-( -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Hello Francois, Am 30.03.2016 um 09:46 schrieb Francois Gouget:
On Fri, 25 Mar 2016, Francois Gouget wrote:
On Fri, 25 Mar 2016, Bernhard Übelacker wrote: [...]
one point that could be related is the usage of function local static variables. When all of these got the "static" removed, I do not get the failures anymore. However I could not prove this with testbot as an empty patch did also succeed.
I have not found static directives that I could remove to fix the dinput8 failures. Which test did it make a difference for? Could you send a diff?
All I could find to fix this is to add 'CFLAGS = -d -O0' in the test's Makefile.in but that does seem like a nice workaround :-(
I attached a diff to this mail or see https://testbot.winehq.org/JobDetails.pl?Key=21671 In my tests it started to fail in a vm when just one of these "statics" was left. Kind regards, Bernhard
I have rechecked this to make sure the test does not have a subtle bug that causes it to depend on the stack layout. In the process I have reduced the test to the minimum set necessary to reproduce the bug (see attachment). But in the end I did not find anything wrong so it does look like a compiler bug. I don't know how to proceed from there. * I think it would be better if someone more knowlegeable than me reported this bug to the MinGW guys. Maybe someone who could undertand what happens in the assembly code? * On the Wine side it would really be nice to get this test (and the three others that are impacted) to stop failing. But removing all the static directives really does not feel right. Would it be better to arrange for these tests to be compiled with -O0? Any other cleaner workaround. So I'm really hoping someone can step up and move this forward. Here are the relevant bugs: * dinput8:dinput regression caused by new compiler https://bugs.winehq.org/show_bug.cgi?id=40384 * usp10:usp10 regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40385 * wininet:url regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40386 * Unexplained new random comctl32:header failure (cross-compiler issue?) https://bugs.winehq.org/show_bug.cgi?id=40442 -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
I have added binaries compiled with my MinGW with -O2 and -O0, and compiled with the TestBot compiler. I also added assembly files and compiler version information. All of this is available at: http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz For immediate reference: My compiler is the Debian Testing compiler (buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The TestBot compiler is the Debian 7.4 compiler (not buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And the WineTest.exe binary is compiled with the Debian 8 compiler which is presumably close to the current Debian Testing one. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ A particle is an irreducible representation of the Poincaré Group - Eugene Wigner
Am 24.04.2016 um 21:12 schrieb Francois Gouget:
I have added binaries compiled with my MinGW with -O2 and -O0, and compiled with the TestBot compiler. I also added assembly files and compiler version information. All of this is available at:
http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
For immediate reference: My compiler is the Debian Testing compiler (buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The TestBot compiler is the Debian 7.4 compiler (not buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the WineTest.exe binary is compiled with the Debian 8 compiler which is presumably close to the current Debian Testing one.
Any update on this? Downgrade the compiler? Fix it upstream and compile mingw-w64 from scratch?
Am 24.04.2016 um 21:12 schrieb Francois Gouget:
I have added binaries compiled with my MinGW with -O2 and -O0, and compiled with the TestBot compiler. I also added assembly files and compiler version information. All of this is available at:
http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
For immediate reference: My compiler is the Debian Testing compiler (buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The TestBot compiler is the Debian 7.4 compiler (not buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the WineTest.exe binary is compiled with the Debian 8 compiler which is presumably close to the current Debian Testing one.
What happens if we compile it using Clang? (totally easy to do so by using wclang [1] to generate a wrapper around clang and mingw-w64) Or for me to try it, what's the best way to verify? does it depend on the wine version somewhat? [1] https://github.com/tpoechtrager/wclang
Am 26.06.2016 um 17:31 schrieb André Hentschel:
Am 24.04.2016 um 21:12 schrieb Francois Gouget:
I have added binaries compiled with my MinGW with -O2 and -O0, and compiled with the TestBot compiler. I also added assembly files and compiler version information. All of this is available at:
http://fgouget.free.fr/tmp/dinput8-dinput.tar.xz
For immediate reference: My compiler is the Debian Testing compiler (buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 5.3.1 20160205 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
The TestBot compiler is the Debian 7.4 compiler (not buggy): $ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
And the WineTest.exe binary is compiled with the Debian 8 compiler which is presumably close to the current Debian Testing one.
What happens if we compile it using Clang? (totally easy to do so by using wclang [1] to generate a wrapper around clang and mingw-w64) Or for me to try it, what's the best way to verify? does it depend on the wine version somewhat?
I noticed that my mingw-w64 has the same issue, so it was easy to try it out and it works! Could someone install wclang on that machine and make wine using it please? It's as easy as running configure like: ./configure CROSSCC=i686-w64-mingw32-clang ... or ./configure --host=i686-w64-mingw32 CC=i686-w64-mingw32-clang host_alias=i686-w64-mingw32 ... I compiled with (just exchanged i686-w64-mingw32-gcc with i686-w64-mingw32-clang): i686-w64-mingw32-clang -c -o device.cross.o ../../../../dlls/dinput8/tests/device.c -I. -I../../../../dlls/dinput8/tests \ -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 i686-w64-mingw32-clang -c -o dinput.cross.o ../../../../dlls/dinput8/tests/dinput.c -I. -I../../../../dlls/dinput8/tests \ -I../../../include -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 i686-w64-mingw32-clang -c -o testlist.cross.o testlist.c -I. -I../../../../dlls/dinput8/tests -I../../../include \ -I../../../../include -D__WINESRC__ -DWINE_CROSSTEST -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ../../../tools/winegcc/winegcc -o dinput8_crosstest.exe -b i686-w64-mingw32 -B../../../tools/winebuild \ --lib-suffix=.cross.a device.cross.o dinput.cross.o testlist.cross.o \ ../../../dlls/dinput8/libdinput8.cross.a ../../../dlls/ole32/libole32.cross.a \ ../../../dlls/user32/libuser32.cross.a ../../../dlls/advapi32/libadvapi32.cross.a
Hello, just tried to find out when this started exactly. First by using old packages from snapshot.debian.org. That revealed it started between packages: gcc-mingw-w64-i686_4.6.4-4+9_i386.deb gcc-mingw-w64-i686_4.8.2-5+10_i386.deb A git bisect of gcc history points to this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff2a5adaa72fef87cac689a40c... ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit commit ff2a5adaa72fef87cac689a40c23258a30b304c8 Author: hubicka <hubicka(a)138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sun Apr 22 21:28:07 2012 +0000 * lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags. (...much longer commit message...) git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk(a)186687 138bc75d-0d04-0410-961f-82ee72b054a4 :040000 040000 d706bdeafbddb9f5f02474e39a245dca08f3334a 508082a31919fe9e907f70b3b3278d4f8d953fac M gcc Testbot runs: Good: (gcc 62c34bf, last one before ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24283 Bad: (gcc ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24280 Hope this could be of any help to identify the issue. Kind regards, Bernhard Notes: - Did not install gcc build system wide. Instead set the PATH that i686-w64-mingw32-gcc was taken from there. - Initial wine configure step was done using Jessie default gcc-mingw-w64-i686 4.9.1-19+14.3. Then the iterations were just done by removing objects from dlls/dinput8/tests and make dinput8_crosstest.exe. - GCC history before 1e37e371 did segfault while building, therefore started from there. Am 24.04.2016 um 20:30 schrieb Francois Gouget:
I have rechecked this to make sure the test does not have a subtle bug that causes it to depend on the stack layout.
In the process I have reduced the test to the minimum set necessary to reproduce the bug (see attachment). But in the end I did not find anything wrong so it does look like a compiler bug.
I don't know how to proceed from there.
* I think it would be better if someone more knowlegeable than me reported this bug to the MinGW guys. Maybe someone who could undertand what happens in the assembly code?
* On the Wine side it would really be nice to get this test (and the three others that are impacted) to stop failing. But removing all the static directives really does not feel right. Would it be better to arrange for these tests to be compiled with -O0? Any other cleaner workaround.
So I'm really hoping someone can step up and move this forward.
Here are the relevant bugs: * dinput8:dinput regression caused by new compiler https://bugs.winehq.org/show_bug.cgi?id=40384
* usp10:usp10 regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40385
* wininet:url regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40386
* Unexplained new random comctl32:header failure (cross-compiler issue?) https://bugs.winehq.org/show_bug.cgi?id=40442
Hello Francois, "DirectX Software Development Kit" offers in "DirectX Control Panel" to increase the "Debug Output Level". That way one can get another hint from dinput: DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string First I tried to build a dinput8.dll that just dumps the data it gets from dinput-mini.exe, but could not find any difference. So I did some tests with DIACTIONA.lptszActionName member. When the two last characters get replaced by \0 no fault is reported anymore. That way a succeeding exe and the failing differ (nearly) just in the two replaced bytes in lptszActionName. Therefore can we assume that it is not the compilers fault, instead it uncovered a hidden bug either in the test or dinput? Kind regards, Bernhard dinput.c: - { 4, DIMOUSE_YAXIS, 0, { "Y Axis" } } + { 4, DIMOUSE_YAXIS, 0, { "Y Ax\0\0" } } Am 17.07.2016 um 21:02 schrieb Bernhard Übelacker:
Hello, just tried to find out when this started exactly.
First by using old packages from snapshot.debian.org. That revealed it started between packages: gcc-mingw-w64-i686_4.6.4-4+9_i386.deb gcc-mingw-w64-i686_4.8.2-5+10_i386.deb
A git bisect of gcc history points to this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ff2a5adaa72fef87cac689a40c...
ff2a5adaa72fef87cac689a40c23258a30b304c8 is the first bad commit commit ff2a5adaa72fef87cac689a40c23258a30b304c8 Author: hubicka <hubicka(a)138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sun Apr 22 21:28:07 2012 +0000
* lto-symtab.c (lto_varpool_replace_node): Do not merge needed flags. (...much longer commit message...)
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk(a)186687 138bc75d-0d04-0410-961f-82ee72b054a4
:040000 040000 d706bdeafbddb9f5f02474e39a245dca08f3334a 508082a31919fe9e907f70b3b3278d4f8d953fac M gcc
Testbot runs: Good: (gcc 62c34bf, last one before ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24283 Bad: (gcc ff2a5ad) https://testbot.winehq.org/JobDetails.pl?Key=24280
Hope this could be of any help to identify the issue.
Kind regards, Bernhard
Notes: - Did not install gcc build system wide. Instead set the PATH that i686-w64-mingw32-gcc was taken from there. - Initial wine configure step was done using Jessie default gcc-mingw-w64-i686 4.9.1-19+14.3. Then the iterations were just done by removing objects from dlls/dinput8/tests and make dinput8_crosstest.exe. - GCC history before 1e37e371 did segfault while building, therefore started from there.
Am 24.04.2016 um 20:30 schrieb Francois Gouget:
I have rechecked this to make sure the test does not have a subtle bug that causes it to depend on the stack layout.
In the process I have reduced the test to the minimum set necessary to reproduce the bug (see attachment). But in the end I did not find anything wrong so it does look like a compiler bug.
I don't know how to proceed from there.
* I think it would be better if someone more knowlegeable than me reported this bug to the MinGW guys. Maybe someone who could undertand what happens in the assembly code?
* On the Wine side it would really be nice to get this test (and the three others that are impacted) to stop failing. But removing all the static directives really does not feel right. Would it be better to arrange for these tests to be compiled with -O0? Any other cleaner workaround.
So I'm really hoping someone can step up and move this forward.
Here are the relevant bugs: * dinput8:dinput regression caused by new compiler https://bugs.winehq.org/show_bug.cgi?id=40384
* usp10:usp10 regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40385
* wininet:url regression caused by new cross-compiler https://bugs.winehq.org/show_bug.cgi?id=40386
* Unexplained new random comctl32:header failure (cross-compiler issue?) https://bugs.winehq.org/show_bug.cgi?id=40442
Am 27.07.2016 um 02:36 schrieb Bernhard Übelacker:
Hello Francois, "DirectX Software Development Kit" offers in "DirectX Control Panel" to increase the "Debug Output Level".
That way one can get another hint from dinput: DINPUT8: ERROR IDirectInput8::EnumDevicesBySemantics: arg 2: invalid UNICODE string
First I tried to build a dinput8.dll that just dumps the data it gets from dinput-mini.exe, but could not find any difference.
So I did some tests with DIACTIONA.lptszActionName member.
When the two last characters get replaced by \0 no fault is reported anymore. That way a succeeding exe and the failing differ (nearly) just in the two replaced bytes in lptszActionName.
Therefore can we assume that it is not the compilers fault, instead it uncovered a hidden bug either in the test or dinput?
Kind regards, Bernhard
Well, seems like 86cdf0b1cb7a15cb43dd0c600b66f6665aea87d2 indeed fixed it. Thanks!
participants (5)
-
André Hentschel -
Bernhard Übelacker -
Bernhard Übelacker -
Francois Gouget -
Michael Stefaniuc