Microsoft Developer Network > Página Inicial dos Fóruns > Visual C++ General > _CrtIsValidHeapPointer(pUserData) - why is this code broken. (vs2008)
Fazer uma PerguntaFazer uma Pergunta
 

Respondido_CrtIsValidHeapPointer(pUserData) - why is this code broken. (vs2008)

  • segunda-feira, 26 de maio de 2008 11:59tyler000 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     

    I've created two projects in a fresh solution using Microsoft Visual C++ 2008 (Not Express).

     

    1. testui (managed Windows Forms Application /clr /MDd) (from the CLR Windows Forms Application template)

    2. testlib (unmanaged static library /MDd) (from the Empty Project template)

     

    The testui application is unmodified but is made to depend on the testlib.  It has had it's driver modified as follows:

     

    // testui.cpp : main project file.

    #include "stdafx.h"

    #include "Form1.h"

    #include "Test.h"

    using namespace testui;

    [STAThreadAttribute]

    int main(array<System:Tongue Tiedtring ^> ^args)

    {

    Test t;

    // Enabling Windows XP visual effects before any controls are created

    Application::EnableVisualStyles();

    Application:Tongue TiedetCompatibleTextRenderingDefault(false);

    // Create the main window and run it

    Application::Run(gcnew Form1());

    return 0;

    }

     

    Basically identical to the template, just we #include "Test.h" and create Test t;

     

    The testlib static library contains only one class as follows.

     

    // Test.h

    #include <vector>

    class Test

    {

    public:

    Test(void);

    private:

    static std::vector<void *> testvec;

    };

     

    // Test.cpp

    #include "Test.h"

    std::vector<void *> Test::testvec;

    Test::Test()

    {

    }

     

    When I run this program it fails with a Debug Assertion Failed! Expression: _CrtIsValidHeapPointer(pUserData) which of course is raised from _ASSERTE(_CrtIsValidHeapPointer(pUserData)); in dbgheap.c

     

    Why does this happen? && How do I fix this?  I developed this test case because it is occurring with a very large static library that uses a lot of stl based static member data similar to this test case.  Anyway, for completeness I have attached the output produced by vs2008 when it fails.

     

    Any help would be greately appreciated.

     

    Thanks

     

    'testui.exe': Loaded 'C:\Documents and Settings\Devel\Desktop\trees\test\testui\Debug\testui.exe', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\mscoree.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\advapi32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\rpcrt4.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\secur32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcr90d.dll', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcp90d.dll', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcm90d.dll', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\system32\ole32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\gdi32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\user32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\msvcrt.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\imm32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\shlwapi.dll'

    'testui.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll'

    'testui.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.1433_x-ww_5cf844d2\msvcr80.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\shell32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\comctl32.dll'

    'testui.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll'

    'testui.exe': Unloaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Culture.dll'

    'testui.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\mscorlib\32e6f703c114f3a971cbe706586e3655\mscorlib.ni.dll'

    'testui.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\uxtheme.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\msctf.dll'

    'testui.exe' (Managed): Loaded 'c:\Documents and Settings\Devel\Desktop\trees\test\testui\Debug\testui.exe', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorjit.dll'

    'testui.exe': Loaded 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\diasymreader.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\rsaenh.dll'

    'testui.exe' (Managed): Loaded 'C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-ww_597c3456\msvcm90d.dll', Symbols loaded.

    'testui.exe': Loaded 'C:\WINDOWS\assembly\NativeImages_v2.0.50727_32\System\ba0e3a22211ba7343e0116b051f2965a\System.ni.dll'

    'testui.exe' (Managed): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll'

    First-chance exception at 0x7c96c540 in testui.exe: 0xC0000005: Access violation reading location 0x23e7ad1a.

    'testui.exe': Loaded 'C:\WINDOWS\system32\version.dll'

    'testui.exe': Unloaded 'C:\WINDOWS\system32\version.dll'

    'testui.exe': Loaded 'C:\WINDOWS\system32\msctfime.ime'

    testui.exe has triggered a breakpoint

    The program '[0x184] testui.exe: Managed' has exited with code 0 (0x0).

    The program '[0x184] testui.exe: Native' has exited with code 0 (0x0).

     

     

Respostas

  • segunda-feira, 2 de junho de 2008 17:35RobWW Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    I had a very similar problem with one of my mixed (managed and unmanaged) projects. I was using a Winforms with /clr specified for the GUI side calling into unmanaged code that at some point referenced a ATL header. Supposedly the winforms wizard configures the project by default to skip the CRT startup code when any ATL header file is detected and thus the reason for it crashing at the g_allocator initialization (this problem is not in the console /clr version). The fix below essentially reverses what the wizard does. On a side note, I included instructions below to obtain access to MSFTs symbols for use when debugging which helped me find this one, atleast to the point I knew what to search for in Google.

    Link describing the problem
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99715&wa=wsignin1.0

    Anyhow here was what I had to do: add  __DllMainCRTStartup@12 in Force Symbols Reference section in the Linker section of the project settings.


    VS2008 - To configure Symbol Server, open the symbol search path options dialog. (From the Tools menu, click Options. In the left pane of the Options dialog box, Open the Debugging node and click Symbols.) Add the following search path to the search list: http://msdl.microsoft.com/download/symbols. Add a symbol cache directory to the symbol server cache text box. Click OK.
    • Sugerido como RespostaRobWW segunda-feira, 2 de junho de 2008 17:35
    • Marcado como RespostaYan-Fei Wei domingo, 3 de agosto de 2008 14:35
    •  
  • segunda-feira, 26 de maio de 2008 15:01nobugzMVP, ModeradorMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    We are not looking at the code you've got that's crashing.  Your static member definition is not correct.  You'll need to post code that reproduces the Access violation exception as shown in your debug output.  Having the debugger stop at that exception with Debug + Exceptions might help you diagnose the problem.
    • Marcado como RespostaYan-Fei Wei domingo, 3 de agosto de 2008 14:36
    •  

Todas as Respostas

  • segunda-feira, 26 de maio de 2008 15:01nobugzMVP, ModeradorMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    We are not looking at the code you've got that's crashing.  Your static member definition is not correct.  You'll need to post code that reproduces the Access violation exception as shown in your debug output.  Having the debugger stop at that exception with Debug + Exceptions might help you diagnose the problem.
    • Marcado como RespostaYan-Fei Wei domingo, 3 de agosto de 2008 14:36
    •  
  • segunda-feira, 26 de maio de 2008 23:17tyler000 Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Resposta Proposta

    That is all of the code in both of the projects.  There is nothing else.  Commenting out the line Test t; in main stops the exception from occurring.

     

    I'm happy for you to state that the static member definition is incorrect.  But could you give some explanation, I mean if I thought it was incorrect I would have fixed it before posting.

     

    Why isn't it correct?

    What is the correct way to define a static std::vector<...> member in a class?

    Less important but still interesting why doesn't the compiler error/warn?

     

    By the way here is the callstack if I break for debug when it occurrs.

     

    > msvcr90d.dll!_msize_dbg(void * pUserData=0x9e202f1b, int nBlockUse=0x00000002)  Line 1511 + 0x30 bytes C++
      msvcr90d.dll!_dllonexit_nolock(int (void)* func=0x9e607abb, void (void)* * * pbegin=0x0012ee18, void (void)* * * pend=0x0012ee10)  Line 295 + 0xd bytes C
      msvcr90d.dll!__dllonexit(int (void)* func=0x9e607abb, void (void)* * * pbegin=0x0012ee18, void (void)* * * pend=0x0012ee10)  Line 273 + 0x11 bytes C
      testui.exe!_onexit(int (void)* func=0x004055a0)  Line 110 + 0x1b bytes C
      testui.exe!atexit(void (void)* func=0x004055a0)  Line 127 + 0x9 bytes C
      testui.exe!`dynamic initializer for 'Test::testvec''()  Line 3 + 0x32 bytes C++
      [Managed to Native Transition] 
      testui.exe!_initterm(void** pfbegin = 0x00406148, void pfend = ) Line 130 C++
      testui.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative() Line 534 C++
      testui.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize() Line 657 C++
      testui.exe!<CrtImplementationDetails>::LanguageSupport::Initialize() Line 855 C++
      testui.exe!?.cctor@@$$FYMXXZ() Line 901 + 0x9 bytes C++
      [Frames below may be incorrect and/or missing, no symbols loaded for mscorwks.dll] 
      kernel32.dll!7c839736()  
      kernel32.dll!7c809af9()  
      kernel32.dll!7c839736()  
      kernel32.dll!7c809af9()  
      mscoree.dll!7900b1b3()  
      kernel32.dll!7c817067()  

     

    Thanks

    • Sugerido como RespostaRobWW segunda-feira, 2 de junho de 2008 17:20
    •  
  • segunda-feira, 2 de junho de 2008 17:35RobWW Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     Respondido
    I had a very similar problem with one of my mixed (managed and unmanaged) projects. I was using a Winforms with /clr specified for the GUI side calling into unmanaged code that at some point referenced a ATL header. Supposedly the winforms wizard configures the project by default to skip the CRT startup code when any ATL header file is detected and thus the reason for it crashing at the g_allocator initialization (this problem is not in the console /clr version). The fix below essentially reverses what the wizard does. On a side note, I included instructions below to obtain access to MSFTs symbols for use when debugging which helped me find this one, atleast to the point I knew what to search for in Google.

    Link describing the problem
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=99715&wa=wsignin1.0

    Anyhow here was what I had to do: add  __DllMainCRTStartup@12 in Force Symbols Reference section in the Linker section of the project settings.


    VS2008 - To configure Symbol Server, open the symbol search path options dialog. (From the Tools menu, click Options. In the left pane of the Options dialog box, Open the Debugging node and click Symbols.) Add the following search path to the search list: http://msdl.microsoft.com/download/symbols. Add a symbol cache directory to the symbol server cache text box. Click OK.
    • Sugerido como RespostaRobWW segunda-feira, 2 de junho de 2008 17:35
    • Marcado como RespostaYan-Fei Wei domingo, 3 de agosto de 2008 14:35
    •  
  • sexta-feira, 25 de julho de 2008 21:45ddbabich Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     

    I had the exact same problem while using a windows forms application with /clr that depended on a static library that referenced an ATL header, and adding __DllMainCRTStartup@12 in force Symbols Reference sectoin in the Linker section of the project worked for me.  Thanks for posting your solution RobWW.

    • Editadoddbabich sexta-feira, 25 de julho de 2008 21:48added more details
    •  
  • terça-feira, 11 de agosto de 2009 15:20Al_S Medalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuárioMedalhas de usuário
     
    I don't know if the context of my application is the same as yours.  However, adding the mentioned symbol allowed my application to run without throwing an exception _CrtIsValidHeapPointer(pUserData)  I am using a VS2008 C++/CLI Winform project that does use the header atlstr.h (used for CString though not using MFC).  I only get the crash as long as atlstr. is used.

    Adding that (
    __DllMainCRTStartup@12) symbol solved it!

    If I don't put the link in the Symbol Server, can I still use the solution as-is?  Build times are longer with it in as opposed to without.

    Thanks for a huge help

    Jer 29:11