Re: Issue(s) when running winetest on Windows

[Kirill K. Smirnov]

> file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
> file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped.

These lines are displayed via printf (include/wine/test.h: 391).
> msvcrt:file done (0)

And this via xprintf (programs/winetest/main.c: 420), which is wrapper over 
write syscall.

If you need these line be output in appropriate way, try to add fflush(stdout) 
in proper place (into run_test function in include/wine/test.h, I suppose).

--
Kirill

Issue(s) when running winetest on Windows

[Paul Vriens]

Kirill K. Smirnov wrote:
> > file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
> > file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped.
>
> These lines are displayed via printf (include/wine/test.h: 391).
> > msvcrt:file done (0)
>
> And this via xprintf (programs/winetest/main.c: 420), which is wrapper over 
> write syscall.
>
> If you need these line be output in appropriate way, try to add fflush(stdout) 
> in proper place (into run_test function in include/wine/test.h, I suppose).
>
> --
> Kirill

Hi,

finally got around checking this again. The fflush doesn't make a difference, I 
still get:

file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped.
file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped.
file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.
file: 373 tests executed (0 marked as todo, 0 failures), 0 skipped.
msvcrt:file done (0)
msvcrt:headers start dlls/msvcrt/tests/headers.c d7c7cd7f0c
file: 2 tests executed (0 marked as todo, 0 failures), 0 skipped.

Anyone?

This is getting pretty serious now as several test reports that are submitted 
will never be processed. I could of course try and fix this in the parser but I 
do want to know what the issue is. The strange thing is that it only happens in 
the msvcrt test (maybe because it's file related).

Cheers,

Paul.

Issue(s) when running winetest on Windows

[Alexandre Julliard]

Paul Vriens  writes:
> Anyone?
>
> This is getting pretty serious now as several test reports that are
> submitted will never be processed. I could of course try and fix this
> in the parser but I do want to know what the issue is. The strange
> thing is that it only happens in the msvcrt test (maybe because it's
> file related).

The only way is for the parent to wait for the child processes to
terminate, by waiting on the process handles.

Issue(s) when running winetest on Windows

[Jakob Eriksson]

Alexandre Julliard wrote:
> Paul Vriens  writes:
> > Anyone?
> >
> > This is getting pretty serious now as several test reports that are
> > submitted will never be processed. I could of course try and fix this
> > in the parser but I do want to know what the issue is. The strange
> > thing is that it only happens in the msvcrt test (maybe because it's
> > file related).
>
> The only way is for the parent to wait for the child processes to
> terminate, by waiting on the process handles.

By the way.
I also noticed that Windows 95 actually bluescreens on rpcrt4 tests.

regards,
Jakob

Issue(s) when running winetest on Windows

[Paul Vriens]

Jakob Eriksson wrote:
> Alexandre Julliard wrote:
> > Paul Vriens  writes:
> > > Anyone?
> > >
> > > This is getting pretty serious now as several test reports that are
> > > submitted will never be processed. I could of course try and fix this
> > > in the parser but I do want to know what the issue is. The strange
> > > thing is that it only happens in the msvcrt test (maybe because it's
> > > file related).
> >
> > The only way is for the parent to wait for the child processes to
> > terminate, by waiting on the process handles.
>
> By the way.
> I also noticed that Windows 95 actually bluescreens on rpcrt4 tests.
>
> regards,
> Jakob

But not every time? There a 2 reports of your win95 system(s) with the full report.

Cheers,

Paul.

Issue(s) when running winetest on Windows

[Paul Vriens]

Alexandre Julliard wrote:
> Paul Vriens  writes:
> > Anyone?
> >
> > This is getting pretty serious now as several test reports that are
> > submitted will never be processed. I could of course try and fix this
> > in the parser but I do want to know what the issue is. The strange
> > thing is that it only happens in the msvcrt test (maybe because it's
> > file related).
>
> The only way is for the parent to wait for the child processes to
> terminate, by waiting on the process handles.

So what do you call the parent in this case? The winetest executable or the test 
itself? The test itself is probably the only one who knows about the processes 
it spawned/started.

Do you know the reason why msvcrt/file.c uses _spawnvp, where the rest of the 
test use CreateProcess (I've read some where that spawnvp is a wrapper around 
CreateProcess anyway)?

Cheers,

Paul.

Issue(s) when running winetest on Windows

[Paul Vriens]

Paul Vriens wrote:
> Alexandre Julliard wrote:
> > Paul Vriens  writes:
> > > Anyone?
> > >
> > > This is getting pretty serious now as several test reports that are
> > > submitted will never be processed. I could of course try and fix this
> > > in the parser but I do want to know what the issue is. The strange
> > > thing is that it only happens in the msvcrt test (maybe because it's
> > > file related).
> >
> > The only way is for the parent to wait for the child processes to
> > terminate, by waiting on the process handles.
>
> So what do you call the parent in this case? The winetest executable or 
> the test itself? The test itself is probably the only one who knows 
> about the processes it spawned/started.
>
> Do you know the reason why msvcrt/file.c uses _spawnvp, where the rest 
> of the test use CreateProcess (I've read some where that spawnvp is a 
> wrapper around CreateProcess anyway)?
>
> Cheers,
>
> Paul.

Something like this then:

diff --git a/dlls/msvcrt/tests/file.c b/dlls/msvcrt/tests/file.c
index 46ccad6..98c8ada 100644
--- a/dlls/msvcrt/tests/file.c
+++ b/dlls/msvcrt/tests/file.c
@@ -34,6 +34,8 @@
  #include <process.h>
  #include <errno.h>

+static HANDLE prochandles[2];
+
  static void test_fdopen( void )
  {
      static const char buffer[] = {0,1,2,3,4,5,6,7,8,9};
@@ -922,7 +924,7 @@ static void test_pipes(const char* selfname)
      arg_v[3] = str_fdr; sprintf(str_fdr, "%d", pipes[0]);
      arg_v[4] = str_fdw; sprintf(str_fdw, "%d", pipes[1]);
      arg_v[5] = NULL;
-    _spawnvp(_P_NOWAIT, selfname, arg_v);
+    prochandles[0] = (HANDLE)_spawnvp(_P_NOWAIT, selfname, arg_v);
      ok(close(pipes[1]) == 0, "unable to close %d: %d\n", pipes[1], errno);

r=read(pipes[0], buf, sizeof(buf)-1);
@@ -947,7 +949,7 @@ static void test_pipes(const char* selfname)
      arg_v[3] = str_fdr; sprintf(str_fdr, "%d", pipes[0]);
      arg_v[4] = str_fdw; sprintf(str_fdw, "%d", pipes[1]);
      arg_v[5] = NULL;
-    _spawnvp(_P_NOWAIT, selfname, arg_v);
+    prochandles[1] = (HANDLE)_spawnvp(_P_NOWAIT, selfname, arg_v);
      ok(close(pipes[1]) == 0, "unable to close %d: %d\n", pipes[1], errno);
      file=fdopen(pipes[0], "r");

@@ -1004,4 +1006,6 @@ START_TEST(file)
      test_get_osfhandle();
      test_setmaxstdio();
      test_pipes(arg_v[0]);
+
+    WaitForMultipleObjects(2, prochandles, TRUE, 5000);
  }

It's enough for the test on my box to have the lines in the correct order.

Cheers,

Paul.