Re: CSplitterWnd crashes in release build after 2005 upgrade

From:

"Ben Voigt" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.mfc,microsoft.public.vc.debugger,microsoft.public.vc.ide_general

Date:

Wed, 28 Jun 2006 08:21:55 -0500

Message-ID:

<uMjwWXrmGHA.856@TK2MSFTNGP03.phx.gbl>

"lg" <xxx> wrote in message news:OHe4ufgmGHA.2396@TK2MSFTNGP05.phx.gbl...

Hi,

I have run into a problem that has me stopped dead!

I have an existing (and working!) VS 6 application which I have recently
upgraded to VS 2005. The application works without problems when run
built for debug, but crashes below the CreateView() method of CSplitterWnd
when built for release. By turning on the debug switch with the "release"
build (but keeping the release libraries), I was able to get a traceback
which indicates that the access violation occurred in ntdll.dll. The call
stack looks like:

ntdll.dll!7c9012b4()
...
kernel32.dll!7c80e2c5()
kernel32.dll!7c80b53c()
rms.exe!CDllIsolationWrapperBase::GetModuleHandleA() line198
rms.exe!CComCtlWrapper::GetProcAddress_InitCommonControlsEx() line 241
rms.exe!AfxEndDeferRegisterClass() line 4497
rms.exe!CFormView::Create() line 90
rms.exe!CSplitterWnd::CreateView() line291
rms.exe!CMainFrame::OnCreateClient() line 296
...

The RuntimeClass being instantiated in the CreateView() call is apparently
valid (its data looks good in the debugger). The crash happens right at
startup during the CMainFrame::OnCreateClient() call, so the app really
hasn't had much opportunity to corrupt memory yet - it has only executed
"boiler-plate" code so far (besides - it works correctly in debug mode
with or without the debugging heap turned on). The application uses the
multi-threaded, static-linked version of MFC.

The problem only occurs when built in VS 2005. No problems in VS 6!

Any suggestions are welcome!

Find out which optimization causes the problem. Try a combination of no
optimization (ala debug) but with NDEBUG preprocessor variable set and
linked to the release runtime libraries.

My guess is that you have lazy initialization without initializing the
pointer. In debug mode, the pointer is initialized to NULL by the runtime,
so your lazy initializer runs. In release mode, some random value is in
that location initially, your lazy initializer is skipped, and you segfault.

Thanks,

--- leon gordon