Hi,
I'm trying to fix the remaining issues in the kernel32 profile tests. They have to do with the fact that we have extra '\r\n' on Win9x and that we need a timeout. The timeout is already in (1000 msec) but apparently that is not even enough on some boxes.
If I check the current results on one of my boxes I see:
profile.c:977: Test failed: File doesn't match profile.c:992: Test failed: File doesn't match profile.c:1007: Test failed: File doesn't match profile.c:1019: Test failed: File doesn't match
This is exactly at the place where the ok() message is.
For debugging purposes I added
if (lstrcmpA(buf, data)) { trace("buf : (%s)\n", buf); trace("data : (%s)\n", data); }
to check_file_data().
When I now run the test I get (and I omitted the buf/data output here):
profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match
So the linenumbers are not the ones from the original ok() message but instead the ones from the last trace() message.
Any idea?
Am Dienstag, den 31.03.2009, 09:42 +0200 schrieb Paul Vriens:
When I now run the test I get (and I omitted the buf/data output here):
profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match
So the linenumbers are not the ones from the original ok() message but instead the ones from the last trace() message.
Any idea?
Expected behaviour. You must not call trace from within the argument list of an ok() statement. ok()/trace() first sets a global variable to the current location, and then calls a printing function passing and evaluating the parameters. If one of them changes the global variable already set, the location printed is wrong, as you see here.
Regards, Michael Karcher
Michael Karcher wrote:
Am Dienstag, den 31.03.2009, 09:42 +0200 schrieb Paul Vriens:
When I now run the test I get (and I omitted the buf/data output here):
profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match profile.c:835: Test failed: File doesn't match
So the linenumbers are not the ones from the original ok() message but instead the ones from the last trace() message.
Any idea?
Expected behaviour. You must not call trace from within the argument list of an ok() statement. ok()/trace() first sets a global variable to the current location, and then calls a printing function passing and evaluating the parameters. If one of them changes the global variable already set, the location printed is wrong, as you see here.
Regards, Michael Karcher
Thanks for clearing that up.