Crash in windows related to statically initialized code

[GoogleCodeExporter]

NOTE: issue has been "branched" here from issue #99

What steps will reproduce the problem?
1. Link (statically or dynamically)
2. Run an app using static initializations that allocate memory and, at a
later time, free or re-allocate it
3. Crash

What is the expected output? What do you see instead?
App crashes on startup

What version of the product are you using? On what operating system?
TCMalloc 1.1. On both Win Xp 32 bit and Win Vista 32 bit

Please provide any additional information below.
See comments by me on issue #99

Original issue reported on code.google.com by sergio.n...@gmail.com on 1 Apr 2009 at 4:44

[GoogleCodeExporter]

So I'm curious about your comment in the bug report that you fixed things by 
changing
InvalidFree().  Did I read that right?  Windows code shouldn't be using 
InvalidFree().

Can you create a minimal program that reproduces this problem for you, and 
attach it
here?  Also tell how you compiled and linked it.  I'd like to see if I can 
reproduce
this locally.

Original comment by csilv...@gmail.com on 1 Apr 2009 at 4:51

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Ok, I'll see what I can do about creating a minimal proof-of-concept.

In the meantime, here is the stack-trace leading to InvalidFree(). 
More notes are at the bottom.

>   MyApp.exe!TCMalloc_CRASH_internal(bool dump_stats=false, const char *
filename=0x02342248, int line_number=181, const char * format=0x02342298, char *
ap=0x0012f3b0)  Line 77 C++
    MyApp.exe!TCMalloc_CrashReporter::PrintfAndDie(const char * format=0x02342298, ...)
 Line 95 + 0x22 bytes   C++
    MyApp.exe!`anonymous namespace'::InvalidFree(void * ptr=0x0467bdd8)  Line 181 +
0x2b bytes  C++
    MyApp.exe!`anonymous namespace'::do_free_with_callback(void * ptr=0x0467bdd8, void
(void *)* invalid_free_fn=0x00e45c32)  Line 674 + 0x9 bytes C++
    MyApp.exe!`anonymous namespace'::do_free(void * ptr=0x0467bdd8)  Line 706 + 0xe
bytes   C++
    MyApp.exe!`anonymous namespace'::do_realloc_with_callback(void *
old_ptr=0x0467bdd8, unsigned int new_size=256, void * (void *, unsigned int)*
invalid_realloc_fn=0x06180240, unsigned int (void *)* 
invalid_get_size_fn=0x06180180)
 Line 766 + 0x9 bytes   C++
    MyApp.exe!`anonymous
namespace'::LibcInfoWithPatchFunctions<0>::Perftools_realloc(void *
old_ptr=0x0467bdd8, unsigned int new_size=256)  Line 700 + 0x1a bytes   C++
    MyApp.exe!Vector::setAllocSize(int allocSize=64)  Line 42 + 0x16 bytes  C++
    MyApp.exe!Vector::addElement(void * el=0x061adb40)  Line 62 + 0x12 bytes    C++
    MyApp.exe!MyMap::put(void * key=0x061adb40, void * value=0x061a8d20)  Line 151  C++
    MyApp.exe!MyMapStr::put(const char * key=0x0238b374, void * value=0x061a8d20)  Line
65 + 0x1d bytes C++
    MyApp.exe!Logger::getInstance(const char * category=0x0238b374)  Line 423 + 0x1d
bytes   C++
    MyApp.exe!`dynamic initializer for 'logger_''()  Line 25 + 0x28 bytes   C++
    msvcr90d.dll!__initterm()  + 0x1c bytes 
    MyApp.exe!__tmainCRTStartup()  Line 501 + 0xf bytes C
    MyApp.exe!mainCRTStartup()  Line 403    C
    kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes    
    ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes   
    ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes    

Where:
Vector::setAllocSize does basically this:
  ...
  void* newArrPtr = realloc(arrPtr_, allocSize*sizeof(void*));
  ...

and do_free_with_callback jumps to InvalidFree here:

  if (!span) {
>>    (*invalid_free_fn)(ptr);  // Decide how to handle the bad free request
    return;
  }

I got here by adding libtcmalloc_minimal project to my solution (I forgot to 
mention
I'm using VS2008) and linking statically after following the relevant notes 
reported
in README.windows with an exception: where it says:
>> You do not need to depend on the tcmalloc symbol in this case (that is, you 
don't
need to do either step 1 or step 2 from above)
I found that step 2 (entering __tcmalloc in "Force Symbol References") is still
needed, otherwise the hooks are ignored. Maybe I'm doing something wrong, or 
maybe
something is different with VS2008. Not sure about that but if I skip step 2 the
linker just ignores tcmalloc functions.

Original comment by sergio.n...@gmail.com on 1 Apr 2009 at 5:26

[GoogleCodeExporter]

Darn, ok, I see what the problem is now.  More bugs in my realloc code.  I'll 
fix it
up for the next release.

Original comment by csilv...@google.com on 1 Apr 2009 at 5:30

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 1 Apr 2009 at 5:31

• Changed state: Started

[GoogleCodeExporter]

Issue 122 has been merged into this issue.

Original comment by csilv...@gmail.com on 7 Apr 2009 at 3:28

[GoogleCodeExporter]

OK, here's a patch (with another random change thrown in for good measure).  
See if
this fixes the problem for you.

Original comment by csilv...@gmail.com on 7 Apr 2009 at 3:34

Attachments:

• p

[GoogleCodeExporter]

Confirmed.  You're correct, this is the same issue and the patch takes care of 
it.  
Sorry for the extraneous report.

Original comment by Codeben...@gmail.com on 7 Apr 2009 at 5:02

[GoogleCodeExporter]

Works like a charm.
Thanks :)

Original comment by sergio.n...@gmail.com on 9 Apr 2009 at 4:14

[GoogleCodeExporter]

A had a problem with linking tcmalloc to a windows xp application (msvc 2003): 
The
debug version worked (but was slow), the release version crashed. On one 
machine with
a "reloc" message on the console, on another machine there was just the crash 
popup.
The unit-test worked with release and debug version.

The p patch fixed the problem!

Original comment by weidenri...@gmx.de on 15 Apr 2009 at 8:13

[GoogleCodeExporter]

This is fixed in perftools 1.2, just released.

Original comment by csilv...@gmail.com on 18 Apr 2009 at 12:13

• Changed state: Fixed