On Aug 20, 6:17 pm, phil oakleaf <n...@oakleafsoftware.co.uk> wrote:
// couple of very simple classes
class MTest
{
public:
float m_aVal;
float m_bVal;
MTest():m_aVal(0),m_bVal(0) {}
};
class RoomTest
{
public:
MTest *m_mat;
RoomTest():m_mat(NULL) {}
virtual MTest *getMaterial() {return m_mat;}
virtual void testMe()
{
MTest *tt=getMaterial();
tt->m_bVal=45;
tt->m_aVal=46;
}
};
void CcrashTestView::OnDraw(CDC* /*pDC*/)
{
CcrashTestDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if (!pDoc)
return;
// just create a real one
RoomTest testRoom;
// NULL pointer
RoomTest *room=NULL;
// call testMe on the NULL Pointer
room->testMe();
// TODO: add draw code for native data here
}
OK, so I tried this in VS2008, and indeed, it does not look good!
Here's what I have in release build with /02 (maximize speed)
CcrashTestDoc* pDoc = GetDocument();
ASSERT_VALID(pDoc);
if (!pDoc)
01112520 cmp dword ptr [ecx+54h],0
01112524 je CcrashTestView::OnDraw+11h (1112531h)
return;
// just create a real one
RoomTest testRoom;
// NULL pointer
RoomTest *room=NULL;
01112526 xor eax,eax
// call testMe on the NULL Pointer
room->testMe();
01112528 mov eax,dword ptr [eax] <------- AV here
(instruction is "move into ax contents of address at (value of) ax"
ax is 0 due to "xor eax,eax"; since ax is 0, and since 0 is off
limits ;-), this is an AV)
0111252A mov edx,dword ptr [eax+4]
0111252D xor ecx,ecx
0111252F call edx
// TODO: add draw code for native data here
Now...
Crash is right there at 01112528. When I try to run over this, i get:
First-chance exception at 0x01112528 in crashTest.exe: 0xC0000005:
Access violation reading location 0x00000000.
... in the output window.
But when I continue, I get another exception:
First-chance exception at 0x771ab84e in crashTest.exe: 0xC0150010: The
activation context being deactivated is not active for the current
thread of execution.
Here's stack trace:
ntdll.dll!771ab84e()
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
ntdll.dll!771952f6()
user32.dll!766ab9f8()
user32.dll!766b6b3a()
user32.dll!766ae949()
crashTest.exe!CcrashTestApp::InitInstance() Line 122 C++
mfc90u.dll!AfxWinMain(HINSTANCE__ * hInstance=0x01110000,
HINSTANCE__ * hPrevInstance=0x00000000, wchar_t *
lpCmdLine=0x00422950, int nCmdShow=1) Line 37 + 0x7 bytes C++
crashTest.exe!__tmainCRTStartup() Line 578 + 0x1c bytes C
kernel32.dll!754de4a5()
ntdll.dll!771ccfed()
ntdll.dll!771cd1ff()
and here's dissasembly inside ::InitInstance where this happens:
// The main window has been initialized, so show and update it
pMainFrame->ShowWindow(m_nCmdShow);
01111217 mov ecx,dword ptr [esi+4Ch]
0111121A push ecx
0111121B mov ecx,edi
0111121D call CWnd::ShowWindow (11125C4h)
pMainFrame->UpdateWindow();
01111222 mov edx,dword ptr [edi+20h]
01111225 push edx
01111226 call dword ptr [__imp__UpdateWindow@4 (11140C8h)]
<--- exception raised inside this
return TRUE;
0111122C lea ecx,[esp+20h]
So indeed, access violation exception invoked at room->testMe(), is
somehow caught, and you are indeed seeing what you are seeing (program
continues). And if it chokes under Win32, that indeed means that you
caught a difference between Win32 and Win64.
It is possible that an excuse is in now order from my part, but I
believe that your attempts to rely on undefined behavior trump
that ;-)
It is still absolutely not true, however, that your code doesn't crash
- it very well does, it's just that crash is manifested differently,
and is indeed less visible. For example, if under a debugger, you
check "Thrown" box for "Win32 exceptions" in Debug->Exceptions, you
will see that you indeed have an AV at room->testMe() (that's what I
did when debugging this). In fact, if you continue running, you will
see one AV trace in your output window at every call to OnDraw (e.g.
maximizing/restoring a window will provoke WM_PAINT - try it).
Guesses follow: there is some code in the system that catches your
access violation 0xC0000005 andre-throws it as 0xC0150010 (I tried
using SetUnhandledExceptionFilter - my callback ain't called at all,
so exception is indeed caught somewhere).
(Obvoius consequence: If you link statically to MFC, this disappears
and you get your usual crash. This is because 0xC0150010 is related to
SxS, and MCF/CRT DLLs in VC2005+ go through SxS. Eliminate these, and
you are back to square one.)
That makes me wonder: is it possible that you tried your code compiled
with VC2003 under Win32, but with VC2005+ under Win64? (MFC/CRT of
VC2003 don't use SxS) Or is it possible that your code under Win32 is
linked statically to MFC? If so, there's your explanation and it
indeed has nothing to do with 32/64 distinction.
That's as far as I went. I'll be interested to know more (as I am sure
others will, too). Quick googling didn't reveal anything interesting,
but my google-fu might have failed me. I indeed have one elusive bug
that might be elusive due to this, and now I feel compelled to thank
you for making me look. So thanks, Phil!
Goran.
had begun. On Windows 32bit - bang - the problem was caught and
code - anxieties that are not there on 32bit. I can do with fewer
expect on Win64 as well. So, it could be something to do with MFC itself