-----Original Message----- From: Marvin testbot@winehq.org Subject: Re: [PATCH 04/13] oleaut32/tests: Cover GetVarDesc in test_dump_typelib.
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=76622
Your paranoid android.
=== w1064v1809 (64 bit report) ===
oleaut32: typelib.c:5290: Interface test_struct typelib.c:5402: Variable hr typelib.c:5402: Variable b typelib.c:5402: Variable disp typelib.c:5402: Variable bstr typelib.c:5416: Test failed: desc->u.oInst expected 12 got 16
The failures in test_struct are because the field offsets really are different in a 64-bit typelib; the pointers for IDispatch *disp gets bigger, so BSTR bstr moved. I'm not sure how best to fix that; I could easily #ifdef the expected .oInst values, but then it will be a pain to regenerate the info[] stuff that's inlined into typelib.c. Function pointers normalize this checking the index (divided by offset/sizeof(void*) but that doesn't work for var since fields aren't all pointers, just (maybe) some of them. I suppose one could build test_tlb.tlb with --win32 (or --win64) so that it's a consistent set of input data, not architecture-dependent? Suggestions welcome if anyone has a good idea...
Or I could just skip verifying oInst; it's not really related to the custdata or FUNC_DISPATCH bug fixes that were the point of this series, it just wasn't covered before because the whole VARDESC was ignored before, so I tried to fill in some conformance-test coverage, not just narrowly check the fix. Which paid off because I found several more bugs in the FUNC_DISPATCH stuff than the one I started working on...
typelib.c:5290: Interface _f typelib.c:5402: Variable f1 typelib.c:5402: Variable f2 typelib.c:5416: Test failed: desc->u.oInst expected 4 got 8 typelib.c:5290: Interface ff typelib.c:5402: Variable ff1 typelib.c:5402: Variable ff2 typelib.c:5416: Test failed: desc->u.oInst expected 4 got 8
These look look like Marvin actually found a latent widl bug (on x86 too), that just happened to show up in the new coverage. _f and ff are unions, so the offsets should all be 0, but it apparently counted them like a struct. And since that's what the typelib actually says, windows oleaut32 agrees (on x86, where these info[] came from). So these would clear up (and not be architecture-dependent) if I can find the right spot in widl to fix oInst for unions - will check into it tomorrow.
-
Puetz Kevin A