Something's rotten in git today...
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems? Here they are, most recent first: ==== http://buildbot.kegel.com/builders/runtests-default/builds/72 ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123 ... ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so file.c && touch file.ok file.c:933: Tests skipped: Either no authority to volume, or is todo_wine for C:\users\bob\Temp\ err=5 should be 3 file.c:933: Tests skipped: Either no authority to volume, or is todo_wine for C:\users\bob\Temp\removeme\ err=5 should be 3 file.c:933: Tests skipped: Either no authority to volume, or is todo_wine for C:\ err=5 should be 3 file.c:946: Test failed: CreateFileA failed on \\?\C:, hFile 0xffffffffffffffff, err=2, should be 0 ... ==== http://buildbot.kegel.com/builders/runtests-default/builds/70 ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok ... action.c:4792: Test failed: The 'Spooler' service does not exist make: *** [action.ok] Error 1 ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so install.c && touch install.ok install.c:5393: Test failed: Directory not created ... make: *** [install.ok] Error 8 ==== http://buildbot.kegel.com/builders/runtests-default-x86_64/builds/68 ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok ... service.c:2084: Test failed: Winetest Sleep Service: QueryServiceStatusEx() failed le=1727 service.c:2085: Test failed: Winetest Sleep Service: should be stopped state=ff service.c:2092: Test failed: Winetest Sleep Service: the second try should yield the same error: 1728 != 1727 service.c:2098: Test failed: Winetest Sleep Service: 1727 != ERROR_SERVICE_NOT_ACTIVE service.c:2099: Test failed: Winetest Sleep Service: should be stopped state=deadbeef service.c:2188: Test failed: 1728 != ERROR_SERVICE_REQUEST_TIMEOUT service.c:2223: Test failed: Expected success, got error 6 ... make: *** [service.ok] Error 20 ==== http://buildbot.kegel.com/builders/runtests-default/builds/67 ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so action.c && touch action.ok ... action.c:4792: Test failed: The 'Spooler' service does not exist
On Thu, Sep 15, 2011 at 7:27 PM, Alexandre Julliard <julliard(a)winehq.org> wrote:
Dan Kegel <dank(a)kegel.com> writes:
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems?
It smells like the rpcrt4 change.
-- Alexandre Julliard julliard(a)winehq.org
I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems?
It smells like the rpcrt4 change.
I thought so, too.
I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
I've reproduced it twice now in an hour on two quad-core machines with the script for try in `seq 1 100` do echo try $try server/wineserver -k || true rm -rf ~/.wine cd dlls/advapi32/tests rm -f *.ok make test cd ../../msi/tests rm -f action.ok make action.ok cd ../../.. done so it may take me a while to verify that it goes away after reverting the rpc change or to get you a detailed log. In one of the failures, I got the service.ok failure from above: service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123 In the other, I got a crash in service.ok: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding wine: Unhandled page fault on read access to 0x60481043 at address 0x7bc34227 (thread 0021), starting debugger.. err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed out in thread 002a, blocked by 0021, retrying (60 sec) ... I don't get backtraces much anymore because of that darn deadlock (unrelated to the current problem), and btall doesn't seem to show a crash (though it does have some interesting stack traces); see the attachment. Austin may have a related crash in rpcrt4_test.exe.so server.c, see http://bugs.winehq.org/show_bug.cgi?id=28383#c2
On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems?
It smells like the rpcrt4 change.
I thought so, too.
I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
I've reproduced it twice now in an hour on two quad-core machines with the script
for try in `seq 1 100` do echo try $try server/wineserver -k || true rm -rf ~/.wine cd dlls/advapi32/tests rm -f *.ok make test cd ../../msi/tests rm -f action.ok make action.ok cd ../../.. done
so it may take me a while to verify that it goes away after reverting the rpc change or to get you a detailed log.
In one of the failures, I got the service.ok failure from above:
service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123
In the other, I got a crash in service.ok: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding wine: Unhandled page fault on read access to 0x60481043 at address 0x7bc34227 (thread 0021), starting debugger.. err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed out in thread 002a, blocked by 0021, retrying (60 sec) ...
This crash is the most interesting thing by far. It looks like it's somewhere in ntdll. Could you please check where exectly? Ntdll should always get mapped to the same place, so if you didn't make any changes to it in the meantime, you can check it with some random wine process without waiting for the crash to happen again
I don't get backtraces much anymore because of that darn deadlock (unrelated to the current problem), and btall doesn't seem to show a crash (though it does have some interesting stack traces); see the attachment.
Austin may have a related crash in rpcrt4_test.exe.so server.c, see http://bugs.winehq.org/show_bug.cgi?id=28383#c2
On Thu, Sep 15, 2011 at 13:55, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems?
It smells like the rpcrt4 change.
I thought so, too.
I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
I've reproduced it twice now in an hour on two quad-core machines with the script
for try in `seq 1 100` do echo try $try server/wineserver -k || true rm -rf ~/.wine cd dlls/advapi32/tests rm -f *.ok make test cd ../../msi/tests rm -f action.ok make action.ok cd ../../.. done
so it may take me a while to verify that it goes away after reverting the rpc change or to get you a detailed log.
In one of the failures, I got the service.ok failure from above:
service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123
In the other, I got a crash in service.ok: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding wine: Unhandled page fault on read access to 0x60481043 at address 0x7bc34227 (thread 0021), starting debugger.. err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed out in thread 002a, blocked by 0021, retrying (60 sec) ...
This crash is the most interesting thing by far. It looks like it's somewhere in ntdll. Could you please check where exectly? Ntdll should always get mapped to the same place, so if you didn't make any changes to it in the meantime, you can check it with some random wine process without waiting for the crash to happen again
I don't get backtraces much anymore because of that darn deadlock (unrelated to the current problem), and btall doesn't seem to show a crash (though it does have some interesting stack traces); see the attachment.
Austin may have a related crash in rpcrt4_test.exe.so server.c, see http://bugs.winehq.org/show_bug.cgi?id=28383#c2
FWIW, on my local buildbot (debain testing 32-bit), the following tests have been randomly failing lately: kernel32/thread rpcrt4/server setupapi/install user32/menu user32/edit the user32 failures are likely flakiness, but the others may be related to this patch. I'm updating now to revert that patch and will see if that helps. Results are at http://austin987.dyndns.org:8010/ for now, for those curious. Once sorted out, will join main buildbot farm. -- -Austin
On Thu, Sep 15, 2011 at 8:55 PM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel <dank(a)kegel.com> wrote:
On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos <bernhardloos(a)googlemail.com> wrote:
It might be just me, but I've seen five very strange test failures today out of about 30 build/test runs. Has anybody else noticed problems?
It smells like the rpcrt4 change.
I thought so, too.
I admit I'm a bit at a loss, how this could happen. Could you create a +seh,+rpc log? And does it go away, if you revert those changes?
I've reproduced it twice now in an hour on two quad-core machines with the script
for try in `seq 1 100` do echo try $try server/wineserver -k || true rm -rf ~/.wine cd dlls/advapi32/tests rm -f *.ok make test cd ../../msi/tests rm -f action.ok make action.ok cd ../../.. done
so it may take me a while to verify that it goes away after reverting the rpc change or to get you a detailed log.
In one of the failures, I got the service.ok failure from above:
service.c:152: Test failed: Expected success, got error 1060 err:rpc:I_RpcGetBuffer no binding service.c:176: Test failed: Expected ERROR_SERVICE_DOES_NOT_EXIST, got 123
In the other, I got a crash in service.ok: ../../../tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so service.c && touch service.ok err:rpc:I_RpcGetBuffer no binding err:rpc:I_RpcGetBuffer no binding wine: Unhandled page fault on read access to 0x60481043 at address 0x7bc34227 (thread 0021), starting debugger.. err:ntdll:RtlpWaitForCriticalSection section 0x110530 "?" wait timed out in thread 002a, blocked by 0021, retrying (60 sec) ...
This crash is the most interesting thing by far. It looks like it's somewhere in ntdll. Could you please check where exectly? Ntdll should always get mapped to the same place, so if you didn't make any changes to it in the meantime, you can check it with some random wine process without waiting for the crash to happen again
I don't get backtraces much anymore because of that darn deadlock (unrelated to the current problem), and btall doesn't seem to show a crash (though it does have some interesting stack traces); see the attachment.
Austin may have a related crash in rpcrt4_test.exe.so server.c, see http://bugs.winehq.org/show_bug.cgi?id=28383#c2
This patch should fix the problem: http://source.winehq.org/patches/data/79042 I switched it back to use nonoverlapped named pipe functions, as only the ConnectNamedPipe operation actually needs the overlapped mode, so I used a dedicated thread for it. The other option would be to create the overlapped completation event for each read/write operation, but this would result in a lot more overhead. Bernhard
Le 19/09/2011 14:35, Bernhard Loos a écrit :
This patch should fix the problem: http://source.winehq.org/patches/data/79042 I switched it back to use nonoverlapped named pipe functions, as only the ConnectNamedPipe operation actually needs the overlapped mode, so I used a dedicated thread for it. The other option would be to create the overlapped completation event for each read/write operation, but this would result in a lot more overhead. Bernhard Hello.
See the patch I sent on Friday. I guess now it's Alexandre choice between the two solutions. Regards. Jérôme.
participants (6)
-
Alexandre Julliard -
Austin English -
Bernhard Loos -
Dan Kegel -
Jérôme Gardou -
Maarten Lankhorst