976372 - Remove support for compilers which lack support for dynamic_cast<void*>

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect)

Comment 1

[(no longer active)]

Attachment: Remove support for compilers which lack support for dynamic_cast<void*>

Comment 2

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8d8165293e9b

Comment 3

[(no longer active)]

Huh, so turns out that this actually breaks the packaging step on Windows!

Not sure what's going on...

Backed out for now: https://hg.mozilla.org/integration/mozilla-inbound/rev/22d6c5982c53

Comment 4

[(no longer active)]

OK, I tried to reproduce this locally.  During make package, the xpcshell program raises a dialog saying that abort() has been called, which is why the test times out.  Here's a stack:

 	msvcr110d.dll!_NMSG_WRITE(int rterrnum) Line 226	C
 	msvcr110d.dll!abort() Line 62	C
 	msvcr110d.dll!terminate() Line 97	C++
 	xpcshell.exe!__CxxUnhandledExceptionFilter(_EXCEPTION_POINTERS * pPtrs) Line 40	C++
 	kernel32.dll!75ec9d57()	Unknown
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]	
 	ntdll.dll!77110727()	Unknown
 	ntdll.dll!77110604()	Unknown
 	ntdll.dll!771104a9()	Unknown
 	ntdll.dll!770f87b9()	Unknown
 	ntdll.dll!770f878b()	Unknown
 	ntdll.dll!770f872e()	Unknown
 	ntdll.dll!770f87b9()	Unknown
 	ntdll.dll!770f878b()	Unknown
 	ntdll.dll!770b010f()	Unknown
 	KernelBase.dll!75e4b727()	Unknown
 	KernelBase.dll!75e4b727()	Unknown
 	KernelBase.dll!75e4b727()	Unknown
 	msvcr110d.dll!_CxxThrowException(void * pExceptionObject, const _s__ThrowInfo * pThrowInfo) Line 152	C++
>	msvcr110d.dll!__RTCastToVoid(void * inptr) Line 100	C++
 	xul.dll!NS_LogCOMPtrAddRef(void * aCOMPtr, nsISupports * aObject) Line 1161	C++
 	xul.dll!nsGetterAddRefs<nsIFile>::~nsGetterAddRefs<nsIFile>() Line 1326	C++
 	xul.dll!mozilla::BinaryPath::GetFile(const char * argv0, nsIFile * * aResult) Line 147	C++
 	xul.dll!XRE_GetBinaryPath(const char * argv0, nsIFile * * aResult) Line 1540	C++
 	xul.dll!XRE_XPCShellMain(int argc, char * * argv, char * * envp) Line 1353	C++
 	xpcshell.exe!NS_internal_main(int argc, char * * argv, char * * envp) Line 43	C++
 	xpcshell.exe!wmain(int argc, wchar_t * * argv) Line 109	C++
 	xpcshell.exe!__tmainCRTStartup() Line 533	C
 	xpcshell.exe!wmainCRTStartup() Line 377	C
 	kernel32.dll!75ea3677()	Unknown
 	ntdll.dll!770d9d72()	Unknown
 	ntdll.dll!770d9d45()	Unknown

The interesting function is __RTCastToVoid.  Here is the body of the function:

static PVOID __CLRCALL_OR_CDECL FindCompleteObject (
    PVOID *inptr)           // Pointer to polymorphic object
{
    // Ptr to CompleteObjectLocator should be stored at vfptr[-1]
    _RTTICompleteObjectLocator *pCompleteLocator =
        (_RTTICompleteObjectLocator *) ((*((void***)inptr))[-1]);
    char *pCompleteObject = (char *)inptr - COL_OFFSET(*pCompleteLocator);

    // Adjust by construction displacement, if any
    if (COL_CDOFFSET(*pCompleteLocator))
        pCompleteObject -= *(int *)((char *)inptr - COL_CDOFFSET(*pCompleteLocator));
    return (PVOID) pCompleteObject;
}

extern "C" PVOID __CLRCALL_OR_CDECL __RTCastToVoid (
    PVOID inptr)            // Pointer to polymorphic object
    throw(...)
{
    if (inptr == NULL)
        return NULL;

    __try {
        return FindCompleteObject((PVOID *)inptr);
    }
    __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION
              ? EXCEPTION_EXECUTE_HANDLER: EXCEPTION_CONTINUE_SEARCH)
    {
#ifndef _SYSCRT
        throw std::__non_rtti_object ("Access violation - no RTTI data!");
#else
        throw __non_rtti_object ("Access violation - no RTTI data!");
#endif
        return NULL;
    }
}

__RTCastToVoid is just attempting to throw an exception.  Note that FindCompleteObject tries to read something from vfptr[-1], which is presumably what's causing the access violation.  This seems to suggest that dynamic_cast<void*> won't work on MSVC without RTTI (and it does actually warn about this "warning C4541: 'dynamic_cast' used on polymorphic type 'Foo' with /GR-; unpredictable behavior may result".)  I don't know why my small test program run taken from the configure.in program worked and why the compiler didn't even warn.  But I guess it's clear at this point that we cannot fix this bug. :(

Comment 5

[Mike Hommey [:glandium]]

For posterity, it's worth noting the configure test doesn't run on Windows (because it's in a section that is skipped on Windows), and running it on Windows does yield the answer "no", both with MSVC and clang-cl. Incidentally, I'm going to remove the test in bug 1523851, because it relies on running at configure time, which doesn't work on cross compiles ; so in practice the dynamic_cast has been disabled on mac on automation ever since we switched to cross compiles. It doesn't affect local mac builds, though.