mirror of
https://github.com/gperftools/gperftools
synced 2024-12-31 19:52:02 +00:00
d8c0276168
* In pprof, accept URLs without ports but with http:// (rsc) * Refactor sizeclass handling in tcmalloc (bmaurer) * Always log failed calls to FindAllocDetails (mec) * Clarify comments for ProfilerStart* (malcolmr) * Add #include guards to stacktrace_win32-inl.h (glider) * Add ANNOTATE_ENABLE_RACE_DETECTION(enable) (kcc) * Make a contentful NEWS file (csilvers) * Fix addr2line --help (which pprof relies on) for windows (csilvers) * Fixes a bug in tcmalloc's TLS callback on windows -static (wtc) git-svn-id: http://gperftools.googlecode.com/svn/trunk@94 6b5cf1ce-ec42-a296-1ba9-69fdba395a50
110 lines
4.5 KiB
Plaintext
110 lines
4.5 KiB
Plaintext
=== 20 January 2010 ===
|
|
|
|
I've just released perftools 1.5
|
|
|
|
This version has a slew of changes, leading to somewhat faster
|
|
performance and improvements in portability. It adds features like
|
|
`ITIMER_REAL` support to the cpu profiler, and `tc_set_new_mode` to
|
|
mimic the windows function of the same name. Full details are in the
|
|
[http://google-perftools.googlecode.com/svn/tags/perftools-1.5/ChangeLog
|
|
ChangeLog].
|
|
|
|
=== 11 September 2009 ===
|
|
|
|
I've just released perftools 1.4
|
|
|
|
The major change this release is the addition of a debugging malloc
|
|
library! If you link with `libtcmalloc_debug.so` instead of
|
|
`libtcmalloc.so` (and likewise for the `minimal` variants) you'll get
|
|
a debugging malloc, which will catch double-frees, writes to freed
|
|
data, `free`/`delete` and `delete`/`delete[]` mismatches, and even
|
|
(optionally) writes past the end of an allocated block.
|
|
|
|
We plan to do more with this library in the future, including
|
|
supporting it on Windows, and adding the ability to use the debugging
|
|
library with your default malloc in addition to using it with
|
|
tcmalloc.
|
|
|
|
There are also the usual complement of bug fixes, documented in the
|
|
ChangeLog, and a few minor user-tunable knobs added to components like
|
|
the system allocator.
|
|
|
|
|
|
=== 9 June 2009 ===
|
|
|
|
I've just released perftools 1.3
|
|
|
|
Like 1.2, this has a variety of bug fixes, especially related to the
|
|
Windows build. One of my bugfixes is to undo the weird `ld -r` fix to
|
|
`.a` files that I introduced in perftools 1.2: it caused problems on
|
|
too many platforms. I've reverted back to normal `.a` files. To work
|
|
around the original problem that prompted the `ld -r` fix, I now
|
|
provide `libtcmalloc_and_profiler.a`, for folks who want to link in
|
|
both.
|
|
|
|
The most interesting API change is that I now not only override
|
|
`malloc`/`free`/etc, I also expose them via a unique set of symbols:
|
|
`tc_malloc`/`tc_free`/etc. This enables clients to write their own
|
|
memory wrappers that use tcmalloc:
|
|
{{{
|
|
void* malloc(size_t size) { void* r = tc_malloc(size); Log(r); return r; }
|
|
}}}
|
|
|
|
|
|
=== 17 April 2009 ===
|
|
|
|
I've just released perftools 1.2.
|
|
|
|
This is mostly a bugfix release. The major change is internal: I have
|
|
a new system for creating packages, which allows me to create 64-bit
|
|
packages. (I still don't do that for perftools, because there is
|
|
still no great 64-bit solution, with libunwind still giving problems
|
|
and --disable-frame-pointers not practical in every environment.)
|
|
|
|
Another interesting change involves Windows: a
|
|
[http://code.google.com/p/google-perftools/issues/detail?id=126 new
|
|
patch] allows users to choose to override malloc/free/etc on Windows
|
|
rather than patching, as is done now. This can be used to create
|
|
custom CRTs.
|
|
|
|
My fix for this
|
|
[http://groups.google.com/group/google-perftools/browse_thread/thread/1ff9b50043090d9d/a59210c4206f2060?lnk=gst&q=dynamic#a59210c4206f2060
|
|
bug involving static linking] ended up being to make libtcmalloc.a and
|
|
libperftools.a a big .o file, rather than a true `ar` archive. This
|
|
should not yield any problems in practice -- in fact, it should be
|
|
better, since the heap profiler, leak checker, and cpu profiler will
|
|
now all work even with the static libraries -- but if you find it
|
|
does, please file a bug report.
|
|
|
|
Finally, the profile_handler_unittest provided in the perftools
|
|
testsuite (new in this release) is failing on FreeBSD. The end-to-end
|
|
test that uses the profile-handler is passing, so I suspect the
|
|
problem may be with the test, not the perftools code itself. However,
|
|
I do not know enough about how itimers work on FreeBSD to be able to
|
|
debug it. If you can figure it out, please let me know!
|
|
|
|
=== 11 March 2009 ===
|
|
|
|
I've just released perftools 1.1!
|
|
|
|
It has many changes since perftools 1.0 including
|
|
|
|
* Faster performance due to dynamically sized thread caches
|
|
* Better heap-sampling for more realistic profiles
|
|
* Improved support on Windows (MSVC 7.1 and cygwin)
|
|
* Better stacktraces in linux (using VDSO)
|
|
* Many bug fixes and feature requests
|
|
|
|
Note: if you use the CPU-profiler with applications that fork without
|
|
doing an exec right afterwards, please see the README. Recent testing
|
|
has shown that profiles are unreliable in that case. The problem has
|
|
existed since the first release of perftools. We expect to have a fix
|
|
for perftools 1.2. For more details, see
|
|
[http://code.google.com/p/google-perftools/issues/detail?id=105 issue 105].
|
|
|
|
Everyone who uses perftools 1.0 is encouraged to upgrade to perftools
|
|
1.1. If you see any problems with the new release, please file a bug
|
|
report at http://code.google.com/p/google-perftools/issues/list.
|
|
|
|
Enjoy!
|