April 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 2/5] d3d9/tests: Use a separate device for z_range_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6262 Your paranoid android. === w2000pro (32 bit visual) === The test timed out

April 10, 2014

Re: [PATCH 1/5] d3d9/tests: Use a separate device for maxmip_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6261 Your paranoid android. === w2000pro (32 bit visual) === The test timed out

April 10, 2014

Re: [2/2] oleaut32: Fix loading of an empty picture from a non-statable stream.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6260 Your paranoid android. === w2000pro (32 bit olepicture) === olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:202: Test failed: OLP (NULL,..) does not return 0, but 0x8000ffff olepicture.c:203: Test failed: OLP (NULL,..) returns NULL, instead of !NULL olepicture.c:435: Test failed: OleLoadPicture failed with error 0x8000ffff olepicture: unhandled exception c0000005 at 0040A7BD

April 10, 2014

Re: [1/2] oleaut32/tests: Add a test for loading an empty picture from a non-statable stream.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6259 Your paranoid android. === w2000pro (32 bit olepicture) === Unable to set the VM system time: the "nc -q0 '10.42.42.139' '4242'" command returned 1

April 10, 2014

Re: dpnet: Improve Error checking in Get/Set SP (try 4)

by Stefan Dösinger

Am 10.04.2014 um 09:18 schrieb Stefan Dösinger <stefandoesinger(a)gmail.com>: > You shouldn’t have to set client->init = FALSE because you allocate client with HEAP_ZERO_MEMORY. If you prefer to set it for clarity that’s ok with me. > > The same applies to SP_guid, for two reasons: First, it’s already initialized to zeroes, and you’re not reading it unless client->init is set to TRUE, which only happens after a successful SetSP call. > > IMHO you can also correct the indentation in this function, but I’ll leave the decision up to you. To clarify: Only change the indentation when you change something else in the function. /me blames the accidental wine-patches CC on Apple Mail…

April 10, 2014

Re: dpnet: Improve Error checking in Get/Set SP (try 4)

by Nikolay Sivov

Could you reuse some existing file for new tests?

April 10, 2014

Re: dpnet: Improve Error checking in Get/Set SP (try 4)

by Stefan Dösinger

> + hr = IDirectPlay8Address_SetSP(localaddr, &GUID_NULL); > + ok(hr == S_OK, "got 0x%08x\n", hr); > + > + hr = IDirectPlay8Address_SetSP(localaddr, &IID_Random); > + ok(hr == S_OK, "got 0x%08x\n", hr); That’s a step forward, but I also meant that you should call GetSP after setting GUID_NULL manually. > +DEFINE_GUID(GUID_NULL,0,0,0,0,0,0,0,0,0,0,0); Why do you have to define this? (I really don’t know; It may be correct, or maybe you just need #define INITGUID, or something else.) > static HRESULT WINAPI IDirectPlay8AddressImpl_SetUserData(IDirectPlay8Address *iface, > @@ -313,6 +323,8 @@ HRESULT DPNET_CreateDirectPlay8Address(LPCLASSFACTORY iface, LPUNKNOWN punkOuter > return E_OUTOFMEMORY; > } > client->IDirectPlay8Address_iface.lpVtbl = &DirectPlay8Address_Vtbl; > + client->SP_guid = GUID_NULL; > + client->init = FALSE; > client->ref = 0; /* will be inited with QueryInterface */ > return IDirectPlay8AddressImpl_QueryInterface (&client->IDirectPlay8Address_iface, riid, ppobj); > } You shouldn’t have to set client->init = FALSE because you allocate client with HEAP_ZERO_MEMORY. If you prefer to set it for clarity that’s ok with me. The same applies to SP_guid, for two reasons: First, it’s already initialized to zeroes, and you’re not reading it unless client->init is set to TRUE, which only happens after a successful SetSP call. IMHO you can also correct the indentation in this function, but I’ll leave the decision up to you. Cheers, Stefan

April 10, 2014

Re: [PATCH] qedit/tests: Fix a file handle leak on error path (Coverity)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6258 Your paranoid android. === w2000pro (32 bit mediadet) === Unable to set the VM system time: the "nc -q0 '10.42.42.139' '4242'" command returned 1

April 10, 2014

Re: dpnet: Improve Error checking in Get/Set SP (try 4)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6257 Your paranoid android. === w2000pro (32 bit address) === Unable to set the VM system time: the "nc -q0 '10.42.42.139' '4242'" command returned 1

April 10, 2014

Implementing (parts of) BindImageEx

by Bernhard Reiter

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm trying to implement parts of imagehlp's BindImageEx so that at least freezing Python scripts to .exe files (as done by cx_Freeze or py2exe) works -- see [1] (from whose comments #24 and #25 most of this message is copied), and their implementations of the StatusRoutine function [2, 3]. In both cases, BindImageEx is called with BIND_NO_BOUND_IMPORTS | BIND_NO_UPDATE | BIND_ALL_IMAGES as Flags, which I think means that no actual changes to the image's virtual address table are done, but they're only used to determine which DLLs are used by the image. So for cx_Freeze, it would be apparently enough for Wine's BindImageEx stub to iterate over all DLLs whose functions are used by the image, i.e. the exe or dll passed as the ImageName parameter, and call StatusRoutine with the Reason parameter set to BindImportModule, and DllName set to the DLL, while the "Parameter" and "virtualAddress" arguments aren't required for it to work. Py2exe also requires StatusRoutine called with BindImportProcedure as Reason, and will in that case check if Parameter is set to PyImport_ImportModule before it does something, so I think there should be another loop iterating over a DLL's functions, nested in the one mentioned above, and which invokes StatusRoutine with Status set to BindImportProcedure, and with the current function's name as Parameter. I think I have found out the crucial function required to implement this to be ImageDirectoryEntryToDataEx [4] (with dir set to IMAGE_DIRECTORY_ENTRY_IMPORT). Similar iterations like the ones sketched here seem to be found in fixup_imports() (in dlls/ntdll/loader.c) or dump_dir_imported_functions() (in tools/winedump/pe.c, though that isn't using win API functions). So I've tried to implement what I've described above, but unfortunately, I can't seem to figure out the very first part required: obtaining something that can be used as the "base" parameter for ImageDirectoryEntryToDataEx from the ImageName string passed to BindImageEx. I've tried LoadLibraryA(ImageName), LoadLibraryExA(ImageName, NULL, LOAD_LIBRARY_AS_DATAFILE), and MapAndLoad(), but unfortunately, all of them seem to either import all the PE's symbols in a fashion that collides with the already loaded ones (in particular in a python-freezing context, like running "wine C:\\Python27\\python.exe setup.py build" with the test case attached to [1]), or not load them in a way that can be used for ImageDirectoryEntryToDataEx. I'm hoping for someone to help me figure out how to do this... Bernhard [1] http://bugs.winehq.org/show_bug.cgi?id=3591 [2] https://bitbucket.org/anthony_tuininga/cx_freeze/src/de3e8865616a1048d17e95… [3] http://sourceforge.net/p/py2exe/svn/HEAD/tree/trunk/py2exe/source/py2exe_ut… [4] http://source.winehq.org/WineAPI/.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTRa6OAAoJEKYfw19Gd1lo210P/jfWL7wxK1xDviOur3tXhGfE xPduK9CzkirMVKhSCzmCMEeW7o+ZUulOaAyUkpPVc+H9odiiTLM+4KbEp6z9P4FH 3egzgUB84+a+twZGBgTTvlEeZ5XXsvsTy3MCEiMWNbU3NUmU0DMDO2oAGP2XRG9B 55mfggCTaGQhZL11P6zYyNmb1x+oNK5eLdrYshLPuRa7fbnErtA4zYGc+tGbJBBX mTouKETgGYl+2UoYRZzxctXhsOL0AtUST75hbkh+vvD5J/e/ekYRuHVmmQ91mpbv Wdn1FnQFsTjMvdN0S8frWLFNi7gWcysItoHo9xx65E5hfIXq1tuV9VPcJTYwc+4D op8o8BHno45/K3J1VjJfqbWv4fWI7R0dQTO+igARtszux8r5zt0Wla+8TYly152w ozRMqNC7w+u8JSIPmCTL4mU8+ZwDL+Rl41lRNRVMEda/8E4EGnmwBEo6jK/NvLUJ 1/FXizp7EeNKrMLcANmQF9t/WG4xWKVTrpjWwmOVgu2tdZ099u9LqefjOxRZ0vVC qJO0PJmtlhnZsiBUEIk/x8xZ8KlXmG15FYGx/QI9phn9B5jYks7J++Xzn3PmxlqE YadhCZv5RkK/SLNxiGH726rq0dGwS7NSx3aLNaW5Noj2OuDzj57BZr1nxVGmpezy d0kdLN2Il8I/XGgezhao =wM12 -----END PGP SIGNATURE-----

April 9, 2014

Re: The (broken) state of the WineTestBot

by Jeremy White

> So if the Intel config can be put together in the few days it may be > best to restore a minimal set of VMs, and restore the full set after > the new hardware has proven itself. Newman is quick; I think it's reasonable to believe it will have an Intel motherboard by this time tomorrow. Cheers, Jeremy

April 9, 2014

Re: The (broken) state of the WineTestBot

by Francois Gouget

On Wed, 9 Apr 2014, Francois Gouget wrote: [...] > As kvm_adm and kvm_intel are kernel modules, the kernel version might > actually be more important than the QEMU one. Indeed my latest tests > seem to indicate that reverting the kernel from the 3.13 to 3.2.0 fixes > the VM corruption issues (I also tested 3.14rc7 which did not help). This is confirmed: * The 3.2.0 kernel does not corrupt the VMs but might be causing the VM host crash that happens once in a while * The 3.12, 3.13.1 and 3.14rc7 kernels corrupt the VMs in short order and thus are not usable. Anyway, I have reverted the VM host to the 3.2.0 kernel and restored the build and Windows 2000 VMs. I'm also hoping the git apply failures will be fixed after doing tonight's Git update. The tests also confirm that the Dr6 bug is present all the way to the 3.13.1 kernel and is fixed in 3.14rc7. Huw probably found the commit that fixed it so there's potentially hope of backporting it: 73aaf249ee2287b4686ff079dcbdbbb658156e64 http://o.cs.uvic.ca:20810/perl/cid.pl?cid=73aaf249ee2287b4686ff079dcbdbbb65… I could theoretically restore all the VMs, redo their live snapshots for QEMU 1.7.0, probably also do a Windows update for XP and greater since the most up to date configurations are now essentially a year old, but that will take a day or two. The live snapshots would also have to be redone if we switch to Intel (but the poweredoff post-Windows update snapshots should be reusable). The advantage of switching to Intel is that it seems to be more tested upstream, and that both Huw and I have Intel systems. So it let us detect and potentially fix such issues before changing the WineTestBot configuration. It may also fix the occasional host crashes. But this state of affairs is pretty disappointing. So if the Intel config can be put together in the few days it may be best to restore a minimal set of VMs, and restore the full set after the new hardware has proven itself. -- Francois Gouget <fgouget(a)codeweavers.com>

April 9, 2014

Re: [5/5] taskschd: Forward IRegisteredTask::get_Enabled to SchRpcGetTaskInfo.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6250 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [4/5] taskschd: Forward IRegisteredTask::get_State to SchRpcGetTaskInfo.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6249 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [3/5] schedsvc: Add SchRpcGetTaskInfo stub implementation.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6248 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [2/5] schedsvc: Add some tests for SchRpcGetTaskInfo.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6247 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [1/5] schedsvc: Return correct error code when a being loaded xml doesn't exist.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6246 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [PATCH 5/5] d3d9/tests: Use a separate device for offscreen_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6243 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [PATCH 4/5] d3d9/tests: Use a separate device for ds_size_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6242 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [PATCH 3/5] d3d9/tests: Use a separate device for alpha_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6241 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [PATCH 2/5] d3d9/tests: Use a separate device for shademode_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6240 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: [PATCH 1/5] d3d9/tests: Use a separate device for srgbtexture_test().

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=6239 Your paranoid android. === build (build) === Patch failed to apply

April 9, 2014

Re: The (broken) state of the WineTestBot

by Jeremy White

> Short term goal > --------------- > > Restore the WineTestBot to a working state! Francois, We can get an Intel based motherboard rapidly - would that be a faster path forward than trying to understand the AMD failures? Cheers, Jeremy

April 9, 2014

Re: [PATCH 1/2] ntdll: Add a replacement getmntent for Android.

by Vitaly Lipatov

Huw Davies писал 2014-04-08 12:30: > On Tue, Apr 08, 2014 at 12:18:23PM +0400, Vitaly Lipatov wrote: >> I think the more appropriate place for a missed libc function is >> libs/port. > > If it is ever needed by another dll, then it can get moved there. I guess we use libs/port not for common used code, but for system depended code. It allows us make the code more portable. From my view, it is better do not place system related code in a dll at all. That code placed in ntdll. But it is NT dll, not Android dll. Just IMHO. -- Vitaly Lipatov Etersoft

April 9, 2014

The (broken) state of the WineTestBot

by Francois Gouget

My apologies for this last bout of WineTestBot brokenness. It all started when the VM host froze late last Friday and could not be remotely rebooted. So Newman power-cycled it Monday morning. He also suggested upgrading the kernel in the hope that this would avoid further crashes which I agreed to. Then I decided to upgrade to QEMU 1.7 in the hope of fixing the Dr6 ntdll:exception failures, or at least be in a better position to do so. Of course that entails redoing all the live VM snapshots (1) but I was prepared to do so. Then things went south. The issues ---------- I initially ran into some SELinux incompatibilities and then into QEMU/Libvirt incompatibilities (2). Then the VMs were suspending after a few seconds which turned out to be because the disk was full. My fault: I keep too many VM backups so the new VM backups I created finished filling it. That corrupted some VMs which, ironically, I was able to restore from backup after deleting older backups. Now the host now has a sane amount of free disk space and monitor it closely. But the real problem is that now the VMs get corrupted after a bit of use. This manifests through a couple of symptoms: * Sometimes the build VM will detect EXT4 filesystem corruption, remount '/' as read-only and obviously stop working properly. * Sometimes no filesystem corruption is detected but the content of files gets corrupted. For instance this is what caused all the 'Missing build status line' errors when half of the WineTestBot Build.pl sscript got lost. I suspect this also caused a round of build failures related to memcmp() being missing. * Sometimes the wtbbuild ends up at the grub prompt and complains that it cannot find the filesystem. Since these are live snapshots this is presumably preceded by a crash+reboot of the guest. * Sometimes, after qemu has been properly stopped, a 'qemu-img check' finds a lot of errors. Sometimes not despite the VM being broken. * The Windows 2000 VM also sometimes goes south: it resets and fails to reboot complaining some checksum is corrupted (probably that of the Windows boot loader). Of course QEMU behaves while I'm updating a VM's live snapshot. It's only after I've spent time doing so and creating a backup that it break the VM (thus also casting doubt into the trustworthiness of the new backup). Further compounding the problems, once the WineTestBot is on a tear compiling a bunch of patches on the lone build VM it's unstoppable (3). It also tends to get stuck whenever I restart libvirt or the VM host (a known issue I was working on before this episode). The strange thing is that QEMU 1.7 seems to work fine on my test environment. However it now appears that QEMU has at least three very different codepaths: * User-mode emulation which is slow and should not be used. * kvm_intel, uses the Intel VMX instructions, is used on my (Intel) test environment, has the icebp bug, but seems to otherwise be reliable. * kvm_amd, uses the AMD SVM instructions, is used by the WineTestBot's (AMD) VM host, has the Dr6 bug, and has been unreliable since last weekend. As kvm_adm and kvm_intel are kernel modules, the kernel version might actually be more important than the QEMU one. Indeed my latest tests seem to indicate that reverting the kernel from the 3.13 to 3.2.0 fixes the VM corruption issues (I also tested 3.14rc7 which did not help). A corrollary is that any QEMU tests I can do in my home environment are likely to be poor predictors for what will happen on the production VM host. Indeed it's because QEMU 1.7.0 seems to work fine here that I decided to upgrade the VM host. Short term goal --------------- Restore the WineTestBot to a working state! The current hope is that just reverting to a pre-3.13 kernel, maybe 3.2.0 will do the trick. That would make it possible to stick with QEMU 1.7.0 (Debian 7.0 (Stable/Wheezy) has 1.1.2 which is really too old but Wheezy-Backports has moved on to 1.7.0 so there's no easily accessible 1.6.0 packages to go back to). Longer term goals ----------------- * Solve the VM host crashes. The memory has been tested quite extensively already, and I did a badblocks pass on the hard-drive. Neither found anything. I could then test the process using PrimeNet. but the MRTG graphs did not indicate a tendency to overheat or other such problems. It now seems the crashes may be caused by the 3.2.0 kernel, and probably specifically by the kvm/kvm_amd modules. So finding a more recent kernel that actually works might help. * While I hope the VM host will never crash again, it would be nice to be able to remotely power-cycle it. * It will also be necessary to fix the stability issues in the 3.13 and 3.14 kvm_amd module. However given that I don't have an AMD box at hand and already way too many other things to do I don't see how that's going to happen. Maybe through a bug report once I get a better handle on this. Still the VM host cannot remain stuck on 3.2.0 indefinitely. * Given that on AMD the Dr6 bug still seems to be present in QEMU 2.0/Linux 3.13, it still needs to be fixed. (And the icebp one on Intel would be nice too). * Fix the mysterious 'network timeout' errors we get while waiting for a WineTest task to complete. Unfortunately the first set of patches to tackle them were not really conclusive. So maybe switch to plan B, i.e. blindly reconnect to work around them. That would be quite unsatisfying though. * Then resume work on making the WineTestBot Engine (more) resilient to network outages and VM host crashes. I started patches for that but working on them it became clear that this was entangled with proper handling and diagnostics after 'network timeout' errors. * Then resume work on all the other features and bugs of the WineTestBot. (1) QEmu 1.7.0 cannot restore a 1.6.0 live snapshot made in qemu-system-x86_64 https://bugs.launchpad.net/qemu/+bug/1259499 (2) A known issue caused by QEMU changing the 'qemu-system-x86_64 -cpu help' output format which is parsed by Libvirt to figure out which kinds of CPUs can be emulated. (3) Bug 35946 - Cannot mark a VM for maintenance if it is running a task http://bugs.winehq.org/show_bug.cgi?id=35946 -- Francois Gouget <fgouget(a)codeweavers.com>

April 9, 2014