Something's rotten in git today...

[Austin English]

On Thu, Sep 15, 2011 at 13:55, Bernhard Loos
<bernhardloos at googlemail.com> wrote:
> 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
>>

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