9976 - XP-COM Proxy code crashes when trying to AutoProxy parameters without a typelibrary

Status: VERIFIED FIXED

(Core :: XPCOM, defect, P1)

Description

[travis]

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #358181
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=358181
Imported into Bugzilla on 07/15/99 22:30)

The XPCOM Proxy code crashes when trying to marhal or autoproxy a parameter that
there isn't a typelib for.  It should instead return a Proxy error nsresult.
Perhaps NS_ERROR_PROXY_INVALID_PARAMETER which would be the same as "#define
RPC_E_INVALID_PARAMETER          _HRESULT_TYPEDEF_(0x80010010L)" for COM
compatibility?

Comment 1

[Doug Turner (:dougt)]

I had to add two new error code since I would like to know if the conversion
happens before the REAL meathod is called or after.  The error codes are:

#define NS_ERROR_PROXY_INVALID_IN_PARAMETER        ((nsresult) 0x80010010L)
#define NS_ERROR_PROXY_INVALID_OUT_PARAMETER        ((nsresult) 0x80010011L)

note the different result code.  Is the error code compatiblity a requirement?

Comment 2

[Doug Turner (:dougt)]

I just checked these changes in.  If the two error code is a problem, we can do
a pre-flight check before the real method is ever called.

Comment 3

[Daniel Veditz [:dveditz]]

I can't build anymore, VC5.0 chokes on the fact that not all paths return an
nsresult. How is it working on Tinderbox?

Plus there's a potentially huge memory leak -- you do a QueryInterface() each
time through the loop, but just bail on a failure. Would each of these be a
leak in that case, or does your object destructor take care of that?

I'm reopening until I can get it to build...

Comment 4

[leger]

Clearing Fixed resolution due to ReOpen of this bug.

Comment 5

[Doug Turner (:dougt)]

assigning to dan.

Comment 6

[leger]

Adding verifyme keyword

Comment 7

[leger]

Adding crash keyword

Comment 8

[leger]

Marking Verified.  Please reopen if still an open issue.  Old bug.