Something's rotten in git today...

Bernhard Loos bernhardloos at googlemail.com
Thu Sep 15 13:55:34 CDT 2011


On Thu, Sep 15, 2011 at 8:33 PM, Dan Kegel <dank at kegel.com> wrote:
> On Thu, Sep 15, 2011 at 11:13 AM, Bernhard Loos
> <bernhardloos at 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
>



More information about the wine-devel mailing list