Crash in windows

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Compile libtcmalloc_minimal.dll
2. Link against the dll.
3. Run your executable

What is the expected output? What do you see instead?
It should work, instead I see a crash.

(520.1028): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
libtcmalloc_minimal!tcmalloc::ThreadCache::CreateCacheIfNecessary+0xf9:

The line that fails is:

#ifdef HAVE_TLS
    // Also keep a copy in __thread for faster retrieval
    threadlocal_heap_ = heap; <-- THIS ONE
#endif

libtcmalloc_minimal!tcmalloc::ThreadCache::CreateCacheIfNecessary+0xf9
[c:\google-perftools-1.0\src\thread_cache.cc @ 318]
libtcmalloc_minimal!tcmalloc::ThreadCache::GetCache+0x30
[c:\google-perftools-1.0\src\thread_cache.h @ 337]
libtcmalloc_minimal!`anonymous namespace'::do_malloc+0x12
[c:\google-perftools-1.0\src\tcmalloc.cc @ 629]
libtcmalloc_minimal!`anonymous
namespace'::LibcInfoWithPatchFunctions<1>::Perftools_malloc+0xd
[c:\google-perftools-1.0\src\windows\patch_functions.cc @ 633]
libtcmalloc_minimal!TCMallocGuard::TCMallocGuard+0x4d
[c:\google-perftools-1.0\src\tcmalloc.cc @ 496]
libtcmalloc_minimal!`dynamic initializer for 'module_enter_exit_hook''+0xd
[c:\google-perftools-1.0\src\tcmalloc.cc @ 511]

What version of the product are you using? On what operating system?
Latest from the website (compiled 32 bit, release, my app is also 32bit)
Windows XP Professional x64

Please provide any additional information below.

Original issue reported on code.google.com by kjeremy@gmail.com on 21 Jan 2009 at 4:08

[GoogleCodeExporter]

Forgot to add that I'm compiling with Visual Studio 2008

Original comment by kjeremy@gmail.com on 21 Jan 2009 at 4:09

[GoogleCodeExporter]

Hmm, strange.  Perhaps there's an issue with TLS on your system for some 
reason?  Try
finding the line
   #define HAVE_TLS 1
in src/windows/config.h and delete it (or comment it out) and recompile.  Does 
that
cause the problem to go away?

Debugging remotely is always difficult, so if there's anything more you can 
figure
out about what is going wrong, that would be helpful.

Original comment by csilv...@gmail.com on 21 Jan 2009 at 6:00

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Any chance to take another look at this?  I'm planning a new perftools release 
for
very soon, and it would be nice to get this resolved before then.  I don't have 
VS
2008 to compile with, but on both 2003 and 2005 things work fine on my machine, 
at
least on the testing binaries that are part of the perftools .sln.

Can you test some of these unittests, like tcmalloc_unittest and
tcmalloc_unittest-static, and see if they work ok on your system?

I notice you're running XP x64; even though you compile 32-bit, there may be 
some
issues there, though I can't imagine what they might be.  I don't have a 64-bit
windows to test on, unfortunately.

Original comment by csilv...@gmail.com on 6 Mar 2009 at 8:43

[GoogleCodeExporter]

I see similar issues (crash on app init) linking both dynamically and 
statically on
both 32bit Vista and XP.
The error I get is different and always like this: 
...\google-perftools-1.1\src\tcmalloc.cc:191] Attempt to realloc invalid 
pointer: xxxxxxx

The problem seems to be with static initializations like these in my code:
MyLogger* MyClass::log_ = MyLogger::getInstance("categoryName");

where log_ is declared as:
class MyClass 
{
protected:
  static MyLogger* log_;
...  
}

and where MyLogger::getInstance() allocates some memory that, at a later time, 
can be
reallocated.

Setting a breakpoint on the allocation/reallocation function in MyLogger and on
tcmalloc patch function here:
void* LibcInfoWithPatchFunctions<T>::Perftools_realloc

and running the code higlights that the first few mallocs/reallocs are handled 
by the
CRT, with the tcmalloc hooks kicking in only at a later time.
When this happens tcmalloc may be asked to realloc a memory block that it knows
nothing about.

This just confirms that static initializations in C/C++ are evil and I'll try to
avoid them. 
Anyhow, if a fix/workaround can be found that would be of help :)

Original comment by sergio.n...@gmail.com on 25 Mar 2009 at 11:35

[GoogleCodeExporter]

Oops, this last bug is different: a regression in perftools 1.1 where I didn't
intercept realloc quite right in the windows case after I refactored it a bit.  
I'll
have that fixed in the next release.

As soon as I get it reviewed over here, I'll try to post a patch to the source 
code
that should fix this problem -- it would be great if you could test it.  But 
this is
definitely a different problem than the one folks earlier in this thread were 
seeing.

Original comment by csilv...@gmail.com on 25 Mar 2009 at 6:27

[GoogleCodeExporter]

>> I'll try to post a patch to the source code ...
>> it would be great if you could test it
Sure thing. I'll let you know as soon as you post it.
Thanks :)

Original comment by sergio.n...@gmail.com on 27 Mar 2009 at 6:40

[GoogleCodeExporter]

OK, here's a patch.  It's totally untested, since I don't have a windows machine
handy to test on at the moment, but seems like it *should* work...  I've 
attached it
to this bug report; give it a try and let me know how it works.

Original comment by csilv...@gmail.com on 28 Mar 2009 at 3:07

Attachments:

• p

[GoogleCodeExporter]

Thanks a lot :)
I tested it and it works, more or less.
Here is what happened:

1) applied patch and run project
2) crash a moment later not when re-allocating but when freeing a block 
allocated
during a static init
3) replaced abort() in free crash function with a printf and re-run. It got to 
the
printf only once.
4) Got another crash still when freeing a block, but this time in pagemap.h 
here:

  void* get(Number k) const {
    ASSERT(k >> BITS == 0);
    const Number i1 = k >> LEAF_BITS;
    const Number i2 = k & (LEAF_LENGTH-1);
>>    return root_[i1]->values[i2];
  }

because root_[il] was null.
On my code this event happens only once when exiting a thread (I did not 
investigate
further but it seems it happened when freeing memory allocated for the thread's 
stack).

5) again, added a quick 'n dirty hack to printf a warning and return null if
root_[il] is null.

After that it seems it may work.
Let me know if you want me to investigate further and/or test another patch.

Original comment by sergio.n...@gmail.com on 31 Mar 2009 at 1:13

[GoogleCodeExporter]

OK, this is getting complicated enough that it deserves its own bug report, 
instead
of being part of the bug report that's seemingly related to TLS.  Can you open 
a new
issue for this?  I'm not understanding exactly what's going on yet.

Original comment by csilv...@gmail.com on 31 Mar 2009 at 6:51

[GoogleCodeExporter]

The part of this bug report that has to do with TLS is still open.  Any news on 
this?
 Is it still reproducible in the latest perftools release (1.2)?

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

[GoogleCodeExporter]

The latest perftools has fixed the bug you saw with root_[i1].  Let me know if 
you
still have issues with the TLS line.  If I don't hear anything, I will have to 
close
this bug CannotReproduce.

Original comment by csilv...@gmail.com on 14 Oct 2009 at 11:13

[GoogleCodeExporter]

OK, it's been about 5 months now, so I'm going to close this bug 
CannotReproduce.

Original comment by csilv...@gmail.com on 10 Mar 2010 at 6:05

• Changed state: CannotReproduce