Closed
Bug 976372
Opened 9 years ago
Closed 9 years ago
Remove support for compilers which lack support for dynamic_cast<void*>
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ehsan.akhgari, Assigned: ehsan.akhgari)
References
Details
Attachments
(1 file)
10.08 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•9 years ago
|
||
Assignee | ||
Updated•9 years ago
|
Attachment #8381029 -
Flags: review?(dbaron)
Updated•9 years ago
|
Attachment #8381029 -
Flags: review?(dbaron) → review+
Assignee | ||
Comment 2•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/8d8165293e9b
Assignee | ||
Comment 3•9 years ago
|
||
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
Assignee | ||
Comment 4•9 years ago
|
||
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: 9 years ago
Resolution: --- → WONTFIX
Comment 5•4 years ago
|
||
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.
Description
•