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

RESOLVED WONTFIX

Status

()

defect
RESOLVED WONTFIX
6 years ago
7 months ago

People

(Reporter: Ehsan, Assigned: Ehsan)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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: https://hg.mozilla.org/integration/mozilla-inbound/rev/22d6c5982c53
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. :(
Status: NEW → RESOLVED
Closed: 6 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.