Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=40606 Signed-off-by: Rémi Bernon rbernon@codeweavers.com --- dlls/dnsapi/dnsapi.spec | 2 +- dlls/dnsapi/main.c | 10 +++++++ dlls/dnsapi/tests/Makefile.in | 1 + dlls/dnsapi/tests/cache.c | 49 +++++++++++++++++++++++++++++++++++ include/windns.h | 10 +++++++ 5 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 dlls/dnsapi/tests/cache.c
diff --git a/dlls/dnsapi/dnsapi.spec b/dlls/dnsapi/dnsapi.spec index de0ed1d2b94..0d50c56ec68 100644 --- a/dlls/dnsapi/dnsapi.spec +++ b/dlls/dnsapi/dnsapi.spec @@ -40,7 +40,7 @@ @ stub DnsFreeNetworkInformation @ stub DnsFreeSearchInformation @ stub DnsGetBufferLengthForStringCopy -@ stub DnsGetCacheDataTable +@ stdcall DnsGetCacheDataTable(ptr) @ stub DnsGetDnsServerList @ stub DnsGetDomainName @ stub DnsGetHostName_A diff --git a/dlls/dnsapi/main.c b/dlls/dnsapi/main.c index 6cb3b493b77..4ab294c7c07 100644 --- a/dlls/dnsapi/main.c +++ b/dlls/dnsapi/main.c @@ -111,6 +111,16 @@ BOOL WINAPI DnsFlushResolverCacheEntry_W( PCWSTR entry ) return TRUE; }
+/****************************************************************************** + * DnsGetCacheDataTable [DNSAPI.@] + * + */ +BOOL WINAPI DnsGetCacheDataTable( PDNS_CACHE_ENTRY* entry ) +{ + FIXME( "(%p) stub\n", entry ); + return FALSE; +} + /****************************************************************************** * DnsReleaseContextHandle [DNSAPI.@] * diff --git a/dlls/dnsapi/tests/Makefile.in b/dlls/dnsapi/tests/Makefile.in index 20412e82111..14c8f30fd1f 100644 --- a/dlls/dnsapi/tests/Makefile.in +++ b/dlls/dnsapi/tests/Makefile.in @@ -2,5 +2,6 @@ TESTDLL = dnsapi.dll IMPORTS = dnsapi
C_SRCS = \ + cache.c \ name.c \ record.c diff --git a/dlls/dnsapi/tests/cache.c b/dlls/dnsapi/tests/cache.c new file mode 100644 index 00000000000..cb41b9aa289 --- /dev/null +++ b/dlls/dnsapi/tests/cache.c @@ -0,0 +1,49 @@ +/* + * Tests for dns cache functions + * + * Copyright 2019 Remi Bernon for CodeWeavers + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA + */ + +#include <stdarg.h> +#include <stdio.h> + +#include "windef.h" +#include "winbase.h" +#include "winnls.h" +#include "windns.h" + +#include "wine/test.h" + +static void test_DnsGetCacheDataTable( void ) +{ + BOOL ret; + PDNS_CACHE_ENTRY entry = NULL; + + ret = DnsGetCacheDataTable( NULL ); + ok( !ret, "DnsGetCacheDataTable succeeded\n" ); + + ret = DnsGetCacheDataTable( &entry ); + todo_wine + ok( ret, "DnsGetCacheDataTable failed\n" ); + todo_wine + ok( entry != NULL, "DnsGetCacheDataTable returned NULL\n" ); +} + +START_TEST(cache) +{ + test_DnsGetCacheDataTable(); +} diff --git a/include/windns.h b/include/windns.h index d9a4b9adb07..0bdbd9a5378 100644 --- a/include/windns.h +++ b/include/windns.h @@ -697,6 +697,15 @@ typedef struct _DNS_QUERY_CANCEL char Reserved[32]; } DNS_QUERY_CANCEL, *PDNS_QUERY_CANCEL;
+typedef struct _DNS_CACHE_ENTRY +{ + struct _DNS_CACHE_ENTRY* Next; + const WCHAR *Name; + WORD Type; + WORD DataLength; + ULONG Flags; +} DNS_CACHE_ENTRY, *PDNS_CACHE_ENTRY; + DNS_STATUS WINAPI DnsAcquireContextHandle_A(DWORD,PVOID,PHANDLE); DNS_STATUS WINAPI DnsAcquireContextHandle_W(DWORD,PVOID,PHANDLE); #define DnsAcquireContextHandle WINELIB_NAME_AW(DnsAcquireContextHandle_) @@ -734,6 +743,7 @@ DNS_STATUS WINAPI DnsValidateName_UTF8(PCSTR,DNS_NAME_FORMAT); #define DnsValidateName WINELIB_NAME_AW(DnsValidateName_) BOOL WINAPI DnsWriteQuestionToBuffer_W(PDNS_MESSAGE_BUFFER,PDWORD,PCWSTR,WORD,WORD,BOOL); BOOL WINAPI DnsWriteQuestionToBuffer_UTF8(PDNS_MESSAGE_BUFFER,PDWORD,PCSTR,WORD,WORD,BOOL); +BOOL WINAPI DnsGetCacheDataTable(PDNS_CACHE_ENTRY*);
#ifdef __cplusplus } -- 2.23.0.rc1
Hi,
While running your changed tests, 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=56052
Your paranoid android.
=== build (build log) ===
Task errors: BotError: The VM is not powered on
On 8/30/19 3:03 PM, Marvin wrote:
Hi,
While running your changed tests, 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=56052
Your paranoid android.
=== build (build log) ===
Task errors: BotError: The VM is not powered on
I did a successful run with the same patch here: https://testbot.winehq.org/JobDetails.pl?Key=56051
On Fri, 30 Aug 2019, Rémi Bernon wrote:
On 8/30/19 3:03 PM, Marvin wrote:
Hi,
While running your changed tests, 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=56052
Your paranoid android.
=== build (build log) ===
Task errors: BotError: The VM is not powered on
I did a successful run with the same patch here: https://testbot.winehq.org/JobDetails.pl?Key=56051
Yes, here's what happened: * When it has nothing to do the TestBot picks some VMs that it starts up in advance in the hope they will be needed by the next job.
* Because the build VM is used to provide the Windows binaries for testing on Windows it's needed by almost every job. So its given a high priority and ends up being prepared in advance and thus is recorded by the TestBot as being in the idle state.
* But then there was a power outage so all the VMs got powered off.
* But the TestBot server is on a separate location and was not powered off so it was not aware that the VMs got powered off. The thing is these days the Engine never uses libvirt because these calls are blocking which means if it tries to communicate with a dead VM host of one where libvirt is hosed, these calls can block for a long time (up to 10 minutes), which would block the Engine for all that time. Instead it assumes the information it has in its database about the VM is accurate and forks a process whenever it needs to perform an operation on a VM, whether that's running a task, shutting it down or reverting it.
* So it just scheduled the taks on the build VM as usual. But the child process could not communicate with the VMs, checked its state and complained that there was an error because "The VM is not powered on".
What's wrong is that it marked the task as failed. A better recovery mechanism would have been to either mark the VM as "dirty" or "offline" and put the task back in the queued state so the TesBot tries running it again.
The risk is that if the reason why the VM is not usable is not caused by an external factor (such as here), the next round is likely to produce the same result, leading the TestBot to try to run the same highest priority task again and again on the one borked VM.
Finally the reason why you won't see that job as failed if you look a it now is because I restarted it. The user who submitted a job that failed due to a TestBot error gets a button to restart it. A user can only restart his own jobs and I'm not sure it that would have been possible in this case since the job came from a wine-devel email (but the administrator gets to restart anyone's jobs ;-).
Anyway I'll see about tweaking the task scripts to avoid this situation in the future.
On 8/31/19 11:47 AM, Francois Gouget wrote:
On Fri, 30 Aug 2019, Rémi Bernon wrote:
On 8/30/19 3:03 PM, Marvin wrote:
Hi,
While running your changed tests, 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=56052
Your paranoid android.
=== build (build log) ===
Task errors: BotError: The VM is not powered on
I did a successful run with the same patch here: https://testbot.winehq.org/JobDetails.pl?Key=56051
Yes, here's what happened:
When it has nothing to do the TestBot picks some VMs that it starts up in advance in the hope they will be needed by the next job.
Because the build VM is used to provide the Windows binaries for testing on Windows it's needed by almost every job. So its given a high priority and ends up being prepared in advance and thus is recorded by the TestBot as being in the idle state.
But then there was a power outage so all the VMs got powered off.
But the TestBot server is on a separate location and was not powered off so it was not aware that the VMs got powered off. The thing is these days the Engine never uses libvirt because these calls are blocking which means if it tries to communicate with a dead VM host of one where libvirt is hosed, these calls can block for a long time (up to 10 minutes), which would block the Engine for all that time. Instead it assumes the information it has in its database about the VM is accurate and forks a process whenever it needs to perform an operation on a VM, whether that's running a task, shutting it down or reverting it.
So it just scheduled the taks on the build VM as usual. But the child process could not communicate with the VMs, checked its state and complained that there was an error because "The VM is not powered on".
What's wrong is that it marked the task as failed. A better recovery mechanism would have been to either mark the VM as "dirty" or "offline" and put the task back in the queued state so the TesBot tries running it again.
The risk is that if the reason why the VM is not usable is not caused by an external factor (such as here), the next round is likely to produce the same result, leading the TestBot to try to run the same highest priority task again and again on the one borked VM.
Finally the reason why you won't see that job as failed if you look a it now is because I restarted it. The user who submitted a job that failed due to a TestBot error gets a button to restart it. A user can only restart his own jobs and I'm not sure it that would have been possible in this case since the job came from a wine-devel email (but the administrator gets to restart anyone's jobs ;-).
Anyway I'll see about tweaking the task scripts to avoid this situation in the future.
Thanks for the details!
Hi,
While running your changed tests, 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=56052
Your paranoid android.
=== w2008s64 (task log) ===
Task errors: BotError: The VM is not powered on