Crash on call to OleInitialize() about gperftools HOT 7 CLOSED

Hmm, I'm unable to reproduce this.  Here's what I did:

1) In MSVC 7.0, created a new project in the perftools solution, that
  had an ole.cc that looked like this:
    #include <ole2.h>
    int main(void)
    {
      OleInitialize(NULL);
      return 0;
    }
  The new project included ole.cc as the only source file, and
  depended on tcmalloc_minimal.

2) I then did "build" and "debug -> run" in both debug mode and
  release mode.  In both cases the program ran successfully to
  completion each time.

I then tried on mingw/msys (the latest versions -- just downloaded
from the web), and in the msys shell, did

1) ./configure
2) make
3) g++ -o ole ole.cc   -lole32 .libs/libtcmalloc_minimal.a
4) ./ole

and it also ran without error.

Can you describe in more detail what you did?  It sounds like the
problem may be something specific to your system.

craig

Oops, my fault. I didn't specified exactly how to reproduce the problem.
Tried to reproduce the problem your way - works fine.

Here is what I did:

- In MSVC, opened perftools solution
- replaced the contents of the tcmalloc_unittest.cc file with this code:
    #include <ole2.h>
    int main(void)
    {
      OleInitialize(NULL);
      return 0;
    }

- compile, run -> crash


Looks like it's something in the project environment which makes the problem 
appear.

} - replaced the contents of the tcmalloc_unittest.cc file with this
} code:

Do you mean tcmalloc_minimal_unittest?

I tried this as well, and the test passed fine.

Then I tried with tcmalloc_minimal_unittest-static, and indeed I got a
crash when running the program.

Running a statically-linked tcmalloc is a dicey proposition, it looks
like.  Not all the malloc calls get overloaded like I'd like.  My
guess is the project is pulling in a shared library for ole, and
tcmalloc_minimal_unittest-static requires that *everything* be
statically linked in.

I don't plan to worry too much about this, since I don't expect people
to be using tcmalloc much as a static library.  If folks are using
tcmalloc statically for a real application, and discover a crashing
bug similar to this one, that would be a good time to look into this
more.

craig

I can observer the same problem on my system. Replacing the code in
tcmalloc_unittest.cc in "tcmalloc_minimal_unittest" (not the static one) by the 
code
posted by the original submitter, I get a crash as well.

The platform is Windows Server 2003 SP2.

The stack dump given by Visual Studio 2008 can be found below:

>   libtcmalloc_minimal.dll!do_free(void * ptr=0x00392fa8)  Line 2711 + 0x3 
bytes   C++
    libtcmalloc_minimal.dll!Perftools_free(void * ptr=0x00392fa8)  Line 2922 + 0x9
bytes   C++
    uxtheme.dll!MatchThemeClassList()  + 0x13f bytes    
    uxtheme.dll!_OpenThemeDataFromFile()  + 0x23 bytes  
    uxtheme.dll!_OpenThemeData()  + 0x195c bytes    
    uxtheme.dll!_OpenNcThemeData@8()  + 0x57 bytes  
    uxtheme.dll!_LoadNcThemeMetrics()  + 0x2e bytes 
    uxtheme.dll!AcquireNcThemeMetrics()  + 0x38 bytes   
    uxtheme.dll!NewThemeCheck()  + 0x52 bytes   
    uxtheme.dll!OnHooksEnabled()  + 0x13 bytes  
    uxtheme.dll!_ThemeInitApiHook@8()  + 0x1a1 bytes    
    user32.dll!_InitUserApiHook@8()  + 0x1f bytes   
    user32.dll!___ClientLoadLibrary@4()  + 0x1241f bytes    
    ntdll.dll!_KiUserCallbackDispatcher@12()  + 0x2e bytes  
    user32.dll!_NtUserCreateWindowEx@60()  + 0xc bytes  
    user32.dll!__CreateWindowEx@52()  + 0xb5 bytes  
    user32.dll!_CreateWindowExW@48()  + 0x33 bytes  
    ole32.dll!InitMainThreadWnd()  + 0x3b bytes 
    ole32.dll!wCoInitializeEx()  - 0x16572 bytes    
    ole32.dll!_CoInitializeEx@8()  + 0x177 bytes    
    ole32.dll!_OleInitializeEx@8()  + 0x12 bytes    
    ole32.dll!_OleInitialize@4()  + 0xf bytes   
    tcmalloc_minimal_unittest.exe!main()  Line 96   C++
    tcmalloc_minimal_unittest.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes    C
    kernel32.dll!_BaseProcessStart@4()  + 0x23 bytes    

It's too bad I can't reproduce it here. :-(

If you guys can figure out anything by debugging, definitely let me know!  My 
working
theory is that some memory is allocated by the standard crt library, and then 
freed
by tcmalloc, hence the corruption.  This shouldn't be possible with shared 
libraries,
but who knows?

One way to test this would be to put printf statements in tcmalloc's do_alloc 
and
do_free, to print the addresses being allocated and freed.  Then check to see 
if they
match up (if, at least, the free address -- 0x00392fa8 in this case -- is ever 
seen
in a do_alloc).

Perftools 1.0rc1 (just released) has much improved windows support, that I 
expect
will fix this problem.  In fact, I'm so confident (over-confident?) that I'm 
closing
this bug. :-)  Please try this out with perftools 1.0rc1, and reopen the bug if 
it's
still a problem there.