Something's rotten in git today...

Bernhard Loos bernhardloos at
Mon Sep 19 07:35:47 CDT 2011

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

This patch should fix the problem:
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.


More information about the wine-devel mailing list