"Ge van Geldorp" ge@gse.nl writes:
The failures in rpcrt4:server on Windows are caused by an access violation thrown in NdrVaryingArrayUnmarshall() called from get_5numbers(). I've created a minimum get_5numbers() test with Microsoft tools and that throws the same access violation. The access violation disappears when zeroing out the StubMsg before calling NdrClientInitializeNew(), so my guess is Windows NdrVaryingArrayUnmarshall() uses an uninitialized member.
Changelog: NdrVaryingArrayUnmarshall() is broken on Windows
If it's broken on Windows then there's no point in testing it, you can simply remove it.
2009/1/12 Alexandre Julliard julliard@winehq.org:
"Ge van Geldorp" ge@gse.nl writes:
The failures in rpcrt4:server on Windows are caused by an access violation thrown in NdrVaryingArrayUnmarshall() called from get_5numbers(). I've created a minimum get_5numbers() test with Microsoft tools and that throws the same access violation. The access violation disappears when zeroing out the StubMsg before calling NdrClientInitializeNew(), so my guess is Windows NdrVaryingArrayUnmarshall() uses an uninitialized member.
Changelog: NdrVaryingArrayUnmarshall() is broken on Windows
If it's broken on Windows then there's no point in testing it, you can simply remove it.
There's value in the function working in Wine and testing the function stops it being inadvertently broken (probably by me). Microsoft may release a patch to fix it or fix it in a more recent version of Windows.
Rob Shearman wrote:
2009/1/12 Alexandre Julliard julliard@winehq.org:
"Ge van Geldorp" ge@gse.nl writes:
The failures in rpcrt4:server on Windows are caused by an access violation thrown in NdrVaryingArrayUnmarshall() called from get_5numbers(). I've created a minimum get_5numbers() test with Microsoft tools and that throws the same access violation. The access violation disappears when zeroing out the StubMsg before calling NdrClientInitializeNew(), so my guess is Windows NdrVaryingArrayUnmarshall() uses an uninitialized member.
Changelog: NdrVaryingArrayUnmarshall() is broken on Windows
If it's broken on Windows then there's no point in testing it, you can simply remove it.
There's value in the function working in Wine and testing the function stops it being inadvertently broken (probably by me). Microsoft may release a patch to fix it or fix it in a more recent version of Windows.
It looks like we've had exceptions on anything but XP and W2K3 for a long time. The exceptions (as reported on test.winehq.org) for XP and W2K3 started happening after the move to use winetest.exe from test.winehq.org.
From: Paul Vriens [mailto:paul.vriens.wine@gmail.com]
It looks like we've had exceptions on anything but XP and W2K3 for a long time. The exceptions (as reported on test.winehq.org) for XP and W2K3 started happening after the move to use winetest.exe from test.winehq.org.
I'm not sure which compilers are used. When I use VS2008, the test crashes consistently on Windows, since in debug mode local vars are initialized with a 0xcccccccc pattern. MinGW 3.4.5 either initializes the var to zero, or there happens to be a zero at the right location on the stack when the test is executed. With MinGW cross-compiled binaries the test doesn't crash for me on Windows.
Ge.
"Rob Shearman" robertshearman@gmail.com writes:
2009/1/12 Alexandre Julliard julliard@winehq.org:
"Ge van Geldorp" ge@gse.nl writes:
The failures in rpcrt4:server on Windows are caused by an access violation thrown in NdrVaryingArrayUnmarshall() called from get_5numbers(). I've created a minimum get_5numbers() test with Microsoft tools and that throws the same access violation. The access violation disappears when zeroing out the StubMsg before calling NdrClientInitializeNew(), so my guess is Windows NdrVaryingArrayUnmarshall() uses an uninitialized member.
Changelog: NdrVaryingArrayUnmarshall() is broken on Windows
If it's broken on Windows then there's no point in testing it, you can simply remove it.
There's value in the function working in Wine and testing the function stops it being inadvertently broken (probably by me). Microsoft may release a patch to fix it or fix it in a more recent version of Windows.
Simply ignoring crashes does not make for a very reliable test, and exception handling in tests is a tricky business. It would be much better to find a way of exercising the feature that would work on Windows too.
From: Rob Shearman [mailto:robertshearman@gmail.com]
2009/1/12 Alexandre Julliard julliard@winehq.org:
"Ge van Geldorp" ge@gse.nl writes:
Changelog: NdrVaryingArrayUnmarshall() is broken on Windows
If it's broken on Windows then there's no point in testing it, you can simply remove it.
There's value in the function working in Wine and testing the function stops it being inadvertently broken (probably by me). Microsoft may release a patch to fix it or fix it in a more recent version of Windows.
That was my reasoning too. The test itself seems valid, it's just Windows that's broken. BTW, I did some more testing, initializing each of the fields in StubMsg in turn to zero. It's StubMsg->Offset that's causing the problems. I've just submitted a patch that removes the test, Alexandre can pick whichever he prefers.
Ge.
-
Alexandre Julliard -
Ge van Geldorp -
Paul Vriens -
Rob Shearman