Do you have coverity access? if so we can make all these ignore.
If not then tell me and I will go in and mark them ignore.
-aric
Rob Shearman wrote:
2008/10/6 Dan Kegel dank@kegel.com:
Thanks to the half-dozen Wine developers attacking the Coverity warnings, we are slowly making progress.
Here are the warnings that were new as of October 1st and which have not yet been classified. They fall into five areas (four DLLs and one kind of generated code):
CID Checker Func File
...
781 REVERSE_INULL __finally_IEnumFORMATETC_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 782 REVERSE_INULL __finally_IEnumMoniker_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 783 REVERSE_INULL __finally_IEnumSTATDATA_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 784 REVERSE_INULL __finally_IEnumUnknown_RemoteNext_Stub dlls/ole32/ole32_objidl_p.c 785 REVERSE_INULL __finally_IDispatch_RemoteInvoke_Stub dlls/oleaut32/oleaut32_oaidl_p.c 786 REVERSE_INULL __finally_IEnumVARIANT_RemoteNext_Stub dlls/oleaut32/oleaut32_oaidl_p.c 787 REVERSE_INULL __finally_ITypeInfo_RemoteGetNames_Stub dlls/oleaut32/oleaut32_oaidl_p.c 788 REVERSE_INULL __finally_ITypeLib_RemoteFindName_Stub dlls/oleaut32/oleaut32_oaidl_p.c 789 REVERSE_INULL __finally_IEnumConnectionPoints_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 790 REVERSE_INULL __finally_IEnumConnections_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 791 REVERSE_INULL __finally_IEnumOleUndoUnits_RemoteNext_Stub dlls/oleaut32/oleaut32_ocidl_p.c 792 REVERSE_INULL __finally_IPropertyPage_SetObjects_Stub dlls/oleaut32/oleaut32_ocidl_p.c 774 REVERSE_INULL __finally_IEnumBackgroundCopyFiles_Next_Stub dlls/qmgrprxy/qmgrprxy_p.c 775 REVERSE_INULL __finally_IEnumBackgroundCopyJobs_Next_Stub dlls/qmgrprxy/qmgrprxy_p.c 793 REVERSE_INULL __finally_IServer_sum_padded2 dlls/rpcrt4/tests/server_s.c 794 REVERSE_INULL __finally_IServer_sum_padded_conf dlls/rpcrt4/tests/server_s.c 776 REVERSE_INULL __finally_epm_ept_delete programs/rpcss/epm_s.c 777 REVERSE_INULL __finally_epm_ept_insert programs/rpcss/epm_s.c 778 REVERSE_INULL __finally_epm_ept_lookup programs/rpcss/epm_s.c
These are caused by a bug in widl that generates the incorrect code. Compare the code that widl generates: static void __finally_IEnumMoniker_RemoteNext_Stub( struct __frame_IEnumMoniker_RemoteNext_Stub *__frame ) {
__frame->_StubMsg.MaxCount = (unsigned long)__frame->celt; __frame->_StubMsg.Offset = (unsigned long)0; __frame->_StubMsg.ActualCount = (unsigned long)*__frame->pceltFetched; NdrComplexArrayFree( &__frame->_StubMsg, (unsigned char *)__frame->rgelt, (PFORMAT_STRING)&__MIDL_TypeFormatString.Format[448]); if (__frame->rgelt) __frame->_StubMsg.pfnFree(__frame->rgelt); NdrPointerFree( &__frame->_StubMsg, (unsigned char *)__frame->pceltFetched, (PFORMAT_STRING)&__MIDL_TypeFormatString.Format[466]);}
And the code that MIDL generates: {
( _StubMsg.MaxCount = ( unsigned long )celt ) ; ( _StubMsg.Offset = ( unsigned long )0 ) ; ( _StubMsg.ActualCount = ( unsigned long )(pceltFetched ?*pceltFetched : 0) ) ;
NdrPointerFree( &_StubMsg, (unsigned char *)rgelt, &objidl__MIDL_TypeFormatString.Format[812] ); }So in this case and most of the cases like it we shouldn't be calling NdrComplexFree directly. There are other cases where we could potentially generate code that could crash, but the generated code is similar to that generated by MIDL so it highlights a potential bug in MIDL too.
However, it should be noted that these issues won't ever cause a program to crash since we handle both types of exception in CStdStubBuffer_Invoke. It's only a correctness issue as to what return code we pass back to the client.