Static initialization problem

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Build libtcmalloc_minimal
2. Add the following lines anywhere in tcmalloc_unittest.cc :

// Generate enough statically-initialized object destructor stubs to 
generate
// a reallocation of the onext() function pointer table.  Note that an 
array
// of objects is handled by a single function, these must be individual.
struct A { ~A() { } };
A 
a1,b1,c1,d1,e1,f1,g1,h1,i1,j1,k1,l1,m1,n1,o1,p1,q1,r1,s1,t1,u1,v1,w1,x1,y1,
z1;
A 
a2,b2,c2,d2,e2,f2,g2,h2,i2,j2,k2,l2,m2,n2,o2,p2,q2,r2,s2,t2,u2,v2,w2,x2,y2,
z2;

3. Run tcmalloc_minimal_unittest or tcmalloc_minimal_unittest-static

What is the expected output? What do you see instead?

Expect "PASS", get:

..\..\src\tcmalloc.cc:191] Attempt to realloc invalid pointer: 00323A68
This application has requested the Runtime to terminate it in an unusual 
way. Please contact the application's support team for more information.

What version of the product are you using? On what operating system?

Perftools 1.1, Visual Studio 2003, WinXP

Please provide any additional information below.

This is related to the resizing of MSVCRT's internal table of function 
pointers to call on exit (via atexit/onexit calls).  This table is resized 
by doubling it, starting at 32.  A simple application such as the unit 
tests has about 4 entries.  An application with more than about 30 
statically-initialized objects will cause this array to be reallocated 
after the realloc function has been patched, causing an error due to the 
fact that the pointer being passed to tcmalloc's realloc was allocated 
using the default malloc.

This issue relates to a forum post with a more broad discussion of the 
issue:

http://groups.google.com/group/google-perftools/msg/835fc592b4376fbe

Original issue reported on code.google.com by Codeben...@gmail.com on 7 Apr 2009 at 3:18

• Merged into: #120

[GoogleCodeExporter]

Original comment by `` on 18 Jan 2012 at 9:33

[GoogleCodeExporter]

I believe this is the same as issue 120.  See if the patch that's posted there 
fixes
the problem for you as well.  I plan to have it in the next release.

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

• Changed state: Duplicate

[GoogleCodeExporter]

I saw 120, but the description says:

 "Run an app using static initializations that allocate[s] memory and, ... "

The case I'm seeing does not require the initializers to allocate, or even for 
the 
application to allocate or free anything.

Sergio Nalin's static initializers are getting called after tcmalloc is patched 
in, I 
believe (i.e., his allocations *are* going through tcmalloc), so this is 
actually a 
different issue if I'm understanding everything correctly.

Original comment by Codeben...@gmail.com on 7 Apr 2009 at 3:40

[GoogleCodeExporter]

I believe it's the same issue -- realloc isn't correctly handling reallocating 
memory
that was originally allocated with CRT's alloc.  The example in 120 uses
user-allocated data, as opposed to your case which uses internal-library 
allocated
data, but I believe it's the same issue.

The patch is part of issue 120 -- it's associated with comment #6 (I believe; 
the
last comment, in any case).  Patches can be a bit hard to find in google code. 
:-(

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