OLEAUT32: bug 4502 - request for comment before trying to fix
Robert Shearman
rob at codeweavers.com
Tue Mar 14 12:56:32 CST 2006
Alex Villacís Lasso wrote:
> Alex Villacís Lasso wrote:
>
>> I would like to draw attention to bug 4502. This bug can cause any VB
>> application to crash when the DatePicker control is used, and an
>> attempt is made to assign a date value in VB code. Even though I
>> found this bug while testing an application I wrote, this might not
>> be specific to this application. It is only recently that I have some
>> time to dedicate to this bug, but I would like somebody to comment on
>> this.
>>
>> When the sample application is run with WINEDEBUG=ole,variant, the
>> failing invocation looks like this:
>>
>> trace:ole:ITypeInfo_fnInvoke
>> (0x7fdd5440)(0x7fd9f61c,id=20,flags=0x00000004,0x7fa3ee8c,(nil),0x7fa3ee6c,0x7fa3ee9c)
>>
>> trace:ole:dump_DispParms args=1 named args=1
>> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c)
>> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36)
>> trace:ole:dump_Variant ,2006/03/12 00:00:00}
>> trace:ole:ITypeInfo_fnInvoke invoking:
>> L"Value"(1)
>> parm0: L"Value"
>> memid is 00000014
>> Param 0:
>> tdesc.vartype 12 (VT_VARIANT)
>> u.paramdesc.wParamFlags PARAMFLAG_FIN
>> u.paramdesc.lpex (nil)
>> funckind: 1 (pure virtual)
>> invkind: 4 (property put)
>> callconv: 4 (stdcall)
>> oVft: 224
>> cParamsOpt: 0
>> wFlags: 3c
>> elemdescFunc (return value type):
>> tdesc.vartype 25 (VT_HRESULT)
>> u.paramdesc.wParamFlags PARAMFLAGS_NONE
>> u.paramdesc.lpex (nil)
>> helpstring: L"Returns/sets the current date."
>> entry: (null)
>> trace:ole:ITypeInfo_fnInvoke changing args
>> trace:ole:dump_Variant 0x7fa3eef4->{VT_DATE(38788,0x7fa3ec7c)
>> trace:variant:VarUdateFromDate (38788,0x00000000,0x7fa3ec36)
>> trace:ole:dump_Variant ,2006/03/12 00:00:00}
>> trace:variant:VariantChangeTypeEx
>> (0x7fdd5520->(VT_DATE),0x7fa3eef4->(VT_DATE),0x00000400,0x0000,VT_VARIANT)
>>
>> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY))
>> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY))
>> trace:variant:VariantCopyInd
>> (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE))
>> trace:variant:VariantCopy (0x7fa3ec30->(VT_EMPTY),0x7fa3eef4->(VT_DATE))
>> trace:variant:VariantClear (0x7fa3ec30->(VT_EMPTY))
>> trace:variant:VARIANT_Coerce
>> (0x7fa3ec40->(VT_EMPTY),0x00000400,0x0000,0x7fa3ec30->(VT_DATE),VT_VARIANT)
>>
>> trace:variant:VariantClear (0x7fa3ec40->(VT_EMPTY))
>> trace:variant:VariantClear (0x7fa3ec30->(VT_DATE))
>> trace:variant:VariantChangeTypeEx returning 0x80020005,
>> 0x7fdd5520->(VT_DATE)
>> err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_VARIANT
>> from VT_DATE
>> trace:ole:ITypeInfo_fnInvoke -- 0x80020005
>>
>> The Property Put seems to be declared as taking one VT_VARIANT
>> parameter, and the VB code supplies a VT_DATE value. Therefore, an
>> attempt is made to coerce VT_DATE --> VT_VARIANT. However,
>> VariantChangeTypeEx() does not support conversion of *any* kind of
>> variant into VT_VARIANT, so the call fails, and this brings down the
>> application. I was on half a mind to add the VT_VARIANT conversion to
>> VariantChangeTypeEx() myself, but then I checked the tests for this
>> operation, and it seems that the absence of support for VT_VARIANT is
>> actually expected (unless I am misreading the code). Therefore, one
>> of the following two things is happening:
>>
>> 1) There is some error in the reading of the typelib, since a
>> Property Put should not have a VT_VARIANT parameter in the first place.
>> 2) ITypeInfo::Invoke should do the VT_VARIANT conversion itself,
>> precisely because VariantChangeTypeEx() won't do it.
>
The fix is to do the following in the conversion loop in ITypeInfo::Invoke:
if (rgvt[i] == VT_VARIANT)
VariantCopy(&rgvarg[i], src_arg);
else if ((rgvt[i] & VT_BYREF) && !V_ISBYREF(src_arg))
...
I don't have time to put this into patch form and test it, but hopefully
someone else will.
--
Rob Shearman
More information about the wine-devel
mailing list