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 09:57:15 -0500

Message-ID:

<eJPwmMsmGHA.5076@TK2MSFTNGP02.phx.gbl>

"lg" <xxx> wrote in message news:u19pfdrmGHA.4536@TK2MSFTNGP04.phx.gbl...

I can't tell - it is not a question of optimization in my program. I can
exhibit the problem even when I build with no optimization at all, as long
as I am linked with the non-debug libraries.

Then I really think it's an uninitialized pointer. They are set to NULL by
the debug runtime, and left alone (leaving whatever value was already there)
by release.

Do you have anything like:

class CMainWindow : CFrameWnd
{
    CSplashScreen* m_wndSplash;

    CMainWindow()
    {}

    void ShowSplashScreen( void )
    {
        if (!m_wndSplash)
            m_wndSplash = new CSplashScreen(this);
        .
        .
        .
    }
};

Make sure your constructors initialize every member variable in the
initializer list, like:
    CMainWindow()
        : m_wndSplash(NULL)
    {}

For other ideas, are you using any non-standard DLLs? Do they use MFC?

-- leon

"Ben Voigt" <rbv@nospam.nospam> wrote in message
news: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