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
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.
Paul Vriens [email protected] 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.
Alexandre Julliard wrote:
Paul Vriens [email protected] 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
Jakob Eriksson wrote:
Alexandre Julliard wrote:
Paul Vriens [email protected] 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.
Alexandre Julliard wrote:
Paul Vriens [email protected] 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.
Paul Vriens wrote:
Alexandre Julliard wrote:
Paul Vriens [email protected] 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.
-
Alexandre Julliard -
Jakob Eriksson -
Kirill K. Smirnov -
Paul Vriens