Test failure in embeddedobj on some Windows systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This failure was first observed in September this year and now another new dev is facing it:

C:/cygwin/home/Client/lode/dev/core/test/source/xmltesttools.cxx(174) : error : Assertion
Test name: testSaveOnThread::TestBody
equality assertion failed
- Expected: 0.1665in
- Actual  : 1.9685in
- In <>, attribute 'visible-area-width' of '//style:graphic-properties' incorrect value.

Miklos's comments from September:

"I meant that in case we get RPC_E_WRONG_THREAD at
embeddedobj/source/msole/olecomponent.cxx:1018, then we know how to work
things around. It looks like the failing scenario doesn't get this error
code, but fails in a different way, so the visible area (asserted in the
testcase) is wrong exactly the way it was wrong for everyone before
d5cd62164d32273a25913c93aa04be9f7f3a4073."

"Getting RPC_E_WRONG_THREAD on the first try is expected,
what's unexpected is that the 2nd try doesn't work the way the test
wants it."

I asked Hossein how the new dev could continue debugging the issue and he looked into it a bit:

"as I understand from the code, the checks does not happen when the DPI is not 96, in which I think most of the today's displays are not.

embeddedobj/qa/cppunit/msole.cxx:98

CPPUNIT_TEST_FIXTURE(Test, testSaveOnThread)
{
    // Given an embedded object which hosts mspaint data:
    if (Application::GetDefaultDevice()->GetDPIX() != 96)
    {
        return;
    }
.
.
.
}

I changed the code to bypass this condition, and then I saw the test failing as I expected, as it is tailored to 96 dpi only. On my machine, it failed with 0.0555in instead of 0.1665in.

I also wasn't faced with RPC_E_WRONG_THREAD value of `hr`, but it was shown as `S_OK`, passing SUCCEEDED().

Previously, when I wanted to debug multiple values in CppunitTests, I usually dumped them into a temporary file. I think this idea can be used to dump specific values to a set of files, each for a thread. Alternatively, one can switch between threads in the Visual Studio debugger by using the appropriate window, that can be enabled from the debug menu. But, it is not always easy to debug a multi-threaded application."

If someone has ideas on how to figure this out, let me know.

Ilmari



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux