Closed Bug 976372 Opened 9 years ago Closed 9 years ago

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


(Core :: XPCOM, defect)

Not set





(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)




(1 file)

No description provided.
Assignee: nobody → ehsan
Blocks: 935778
Attachment #8381029 - Flags: review?(dbaron)
Attachment #8381029 - Flags: review?(dbaron) → review+
Huh, so turns out that this actually breaks the packaging step on Windows!

Not sure what's going on...

Backed out for now:
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
    if (inptr == NULL)
        return NULL;

    __try {
        return FindCompleteObject((PVOID *)inptr);
    __except (GetExceptionCode() == EXCEPTION_ACCESS_VIOLATION
#ifndef _SYSCRT
        throw std::__non_rtti_object ("Access violation - no RTTI data!");
        throw __non_rtti_object ("Access violation - no RTTI data!");
        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 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. :(
Closed: 9 years ago
Resolution: --- → WONTFIX

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.

You need to log in before you can comment on or make changes to this bug.