Sometime I got std::bad_alloc when I linked tcmalloc with a C application.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Link a C application with tcmalloc.
2. set MALLOCSTATS and HEAPPROFILE.
3. The C application allocates a lot of small memories until out of memory.

What is the expected output? What do you see instead?
  I expected to print memory stats and heap profile file when out of
memory. But I got std::bad_alloc. I think it's a internal allocate failure
of tcmalloc. I know it's a C++ standard behavior. But my application is C,
I can't catch the exception and I can't set a new_handler() to avoid it.
  Maybe you can add a C-compatible function that set a new_handler(). When
out of memory, the new_handler() directly call exit(). Then the MALLOCSTATS
and HEAPPROFILE will take effect.
  By the way, I think it's a important capacity that it can generate a heap
profile file when out of memory. So I do some little hacks in
heap-profiler.cc. I reserve some memories at HeapProfilerStart() and
release them at ~HeapProfileEndWriter(). Do you have a better idea?

What version of the product are you using? On what operating system?
  It's 0.97 on linux.

Original issue reported on code.google.com by lxu4...@gmail.com on 24 Jun 2008 at 12:14

[GoogleCodeExporter]

} I think it's a internal allocate failure of tcmalloc.

Yes, that makes sense to me.  I agree that it would be better if any internal
allocate failures in tcmalloc just caused the allocation to fail, rather than 
dying
in this way.  It sounds like, though, you're using the heap-profiler (and maybe
leak-checker?) as well.  Is it possible the internal allocation error is coming 
from
there?  That's a more difficult situation to know how to deal with -- even if
tcmalloc itself worked well, if the heap-profiler needed memory and couldn't 
get it,
what would be the right thing to do?

It would be great if you could post the stack-traces (if bad_alloc shows them?)
indicating where the failed allocs were coming from.  This would help us change 
them
to some other form, that won't raise an exception.

}   By the way, I think it's a important capacity that it can generate a heap
}  So I do some little hacks in

This is also a good point, and deserves its own bug report I think.  Can you 
re-file
this as a new issue?

Original comment by csilv...@gmail.com on 24 Jun 2008 at 11:49

• Changed state: Accepted

[GoogleCodeExporter]

The exception was without call stack and didn't generate core file. It printed :
allocation failed: 12
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc

And after install v0.98, the std::bad_alloc isn't thrown. 
So I think you can close this issue.

Original comment by lxu4...@gmail.com on 25 Jun 2008 at 7:47

[GoogleCodeExporter]

Problems that resolve themselves!  I love it.  Closed.

Original comment by csilv...@gmail.com on 25 Jun 2008 at 7:55

• Changed state: CannotReproduce