Support manual CoreCLR builds

Update README.md

Interactive coreclr-devel selection

test for errors

WIP: docker build and run

Merge pull request #21 from a-kvochko/update-readme

Add Tizen .NET Memory Profiler guide and screenshots to new README.md.
The original README.md is moved to docs/HEAPTRACK_README.md.

Update screenshots & title

Address latest feedback

Address feedback

Add the original README back

Fix links

Fix formatting

Update README.md

Merge pull request #19 from dotnet/build-from-scrath

Include missing header for PATH_MAX

include missing header for PATH_MAX

Merge pull request #18 from dotnet/calculate-per-managed-type-consumption

Calculate and visualize statistics of memory consumption per managed type

Handle nested classes

Handle multidimensional arrays

Array object support

Format types differently from methods

Trace type name upon object allocation

Merge pull request #17 from dotnet/fix-bytes-amount-divisors

Fix visualization of memory consumption values

Fix visualization of memory consumption values (use 2^10 instead of 10^3 as divisor for bytes -> kilobytes -> megabytes -> etc. calculation).

Merge pull request #16 from dotnet/fix-relative-paths-in-profiler-build-script

Fix handling of relative paths in build script of managed profiler module

Fix handling of relative paths in profiler's build.sh

Merge pull request #15 from dotnet/show-coreclr-consumption

Calculate and show CoreCLR and non-CoreCLR memory consumption

Add logging of CoreCLR/non-CoreCLR memory consumption parts (turned on with --show-coreclr option)

Merge pull request #14 from dotnet/scripts

Add scripts for profiling Tizen .NET applications

Add scripts for tracing Tizen .NET applications.

Merge pull request #13 from dotnet/track-managed-memory

Track managed memory consumption

Fix build of profiler.

Calculate and visualize number of allocations that were not freed.

Refine UI.

Show managed memory consumption in GUI.

Trace managed heap allocations and garbage collections.

Speed up parsing by skipping unused data for each display mode.

Merge pull request #12 from dotnet/managed-call-stacks

Support tracing and visualization of managed call stacks

Use '.' instead of '::' for dividing managed class and function names.

Support --hide-unmanaged-stacks option.

Fix performance of stack tracing.

Fix profiler module.

 - improve performance;
 - fix maximum name length.

Support managed call stacks tracking.

Merge pull request #11 from dotnet/visualization-improvements

GUI improvements

Display locations, which can't be tracked by profiler, as "untracked ()"

Record and display offset of unmanaged function in corresponding module.

Skip zero-sized allocation entries in GUI.

Output module name on charts, if known.

Add malloc/realloc/calloc/posix_memalign/mmap/dlopen function to raw call stack (show them in call trees and flame graphs in GUI).

Merge pull request #10 from dotnet/track-dlopen-and-sbrk

Approximately track and visualize memory allocated from dlopen and sbrk

Add approximate tracking of [heap].

Add approximate trace of mmaps/munmaps from dlopen/dlclose.

Merge pull request #9 from dotnet/fix-several-issues-in-debug-information-tracing

Fix several issues in parsing and tracing debug information

Fix bug with non-copied string in libbacktrace

Fix parsing ELF.

Fix handling of missing build-id.

Merge pull request #8 from dotnet/fix-posix-memalign

Fix accounting for posix_memalign-allocated memory

Fix accounting posix_memalign.

Merge pull request #7 from dotnet/track-mmap-munmap

Track and visualize physical memory consumption for mmap-allocated regions

Hide unnecessary parts of GUI in each display mode.

Add command line options for setting part of memory consumption to display.

Fix calculating peak RSS.

Handle total cost updates upon mmap/munmap and physical memory consumption update in analyzer.

Calculate mmap/munmap memory consumption per call stack.

Process mmap/munmap and smaps trace items in analyzer.

Maintain address ranges information in analyzer.

Trace /proc/self/smaps by timer.

Add mmap/munmap to interpret's output.

Add empty trackers of mmap/munmap.

Introduce display modes (malloc, Private_Dirty, Private_Clean, Shared = Shared_Clean + Shared_Dirty).

Merge pull request #6 from dotnet/fix-backtraces-on-armel

Fix calculating unmanaged code backtraces on armel

Apply patch https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01209.html to libbacktrace.

Author of the applied patch is Denis Khalikov <d.khalikov@partner.samsung.com>

Support .rel.plt in try_overwrite_symbols.

Use backtrace instead of unw_backtrace in Trace::fill.

WIP: Include the build-id in the heaptrack output and use it to find libs

GIT_SILENT made messages (after extraction)

GIT_SILENT made messages (after extraction)

Use i18n instead of tr

Add reset view action to flame graph

Find peak memory consumption in first-pass over input data

This allows us to compute the per-allocation peak data only once,
which dramatically improves the runtime of heaptrack's analysis on
large data files that hit many individual peaks until the largest
one is finally reached.

I.e. before this patch, the first pass through the data (without
waiting for the graphs to be generated) on one medium-sized heaptrack
file takes about ~2.4s. With this patch applied, this time goes down
to about ~0.9s. This is despite having to walk through the whole file
twice!

GIT_SILENT made messages (after extraction)

SVN_SILENT made messages (.desktop file) - always resolve ours

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

SVN_SILENT made messages (.desktop file) - always resolve ours

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Format time values larger than 1min in terms of minutes

Restore the caching functionality in StringCache::location

The patch 1b9a59dc broke this by refactoring the code. It forgot
to store the non-cached value back in the faster lookup table.
See the original patch c370b7be for the advantage this fast-path
can bring.

Move time-formatting code into a Util header

Further optimize handling of peak data cost

We now only update the peak costs once we leave the peak. This
allows us to merge multiple consecutive allocations, which each
lead to an increment in the peak memory consumption. Instead of
updating the peak costs every time, we now only update the peaks
once at the end of the peak patter, just before memory is freed
or the record process has finished.

This brings the processing time back to the original ~1.2s I have
seen initially for my real-world data file.

Only update peak costs on the first parse pass

On the second parse pass we can reuse the initial data. This
saves ~200ms of parse time in my test case, and brings the time
down to ~1.6s from 1.8s.

Add missing license headers

Optimize tracking of peak costs

Use a separate container for the potentially frequent write
operations when updating the peak memory consumption of all
allocation locations. This allows us to only update what is
actually required and thus makes better use of our CPU caches.

In one of my example files, this decreases the processing time
from about 2.2s down to 1.8s, i.e. it's about 22% faster. But,
compared to the original approach with the different "peak"
heuristic, which took ~1.2s, we are still about 33% slower.

Make peak memory consumption easier to understand

This changes the meaning of the peak metric, but frequent feedback
was that the value we used to show was confusing.

Previously, we tracked the peak memory consumption individually by
backtrace. Only at the end did we then aggregate the total, at
which point we lose the temporal resolution. The new peak example
shows how this goes wrong: it used to show a "peak" of 275B in
`allocate_something`, while the expected "peak" is actually only
125B.

The new code repurposes the peak metric to mean "contribution to
peak memory consumption". This requires us to update the peak value
for all allocations whenever we hit a new peak, which is a quite
costly procedure and greatly slows down the overall processing time.
One of my test files took ~1.2s in total to be processed before
this patch. Now, it takes ~2.2s in total - so processing is about
45% slower with this patch.

Nevertheless, I think it's worth it as it makes the cost metric
easier to understand and thus hopefully more useful for users of
heaptrack.

Always use KFormat::MetricBinaryDialect

This dialect is much simpler to grasp and usually what
people expect when talking about megabytes and kilobytes.

Hide rows with less than 1% of the cost from the top proxy

This drastically reduces the clutter on the summary page and we
can concentrate on the actual pain-points.

Use fixed formatting for percentages in heaptrack_print

Otherwise we could end up printing 100% as "1.00E2%". Now, we will
print it as "100.00%".

Update comment, this list is sorted by now

Handle fscanf failure when reading RSS from /proc/self/statm

In such situations, disable further read attempts of the RSS value.

Fixes compiler warnings like this one:
src/track/libheaptrack.cpp:339:51: warning:
  ignoring return value of ‘int fscanf(FILE*, const char*, ...)’,
  declared with attribute warn_unused_result [-Wunused-result]

Make sure KF5_FOUND is FALSE when not all components are available

heaptrack_gui needs all components

Do not print zero-cost sub-branches in diff mode

Don't repeat work of KAboutData::setApplicationData()

Show inlined frames

This is a major usability improvement for C++ code. Previously,
when we profiled code with heaptrack that was built with compiler
optimizations enabled, most allocations within container classes
where missing some parent frames. Even more confusing, sometimes
we missed the interesting user frames completely, when they
got inlined.

Now, we add all inlined frames to the heaptrack_print output and
also include them in the heaptrack_gui models. The simple
inlining example added by this pach clearly shows the advantage:

Before all we got is this:

1 calls to allocation functions with 1.23KB peak consumption from
main
  at /home/milian/projects/src/heaptrack/tests/manual/inlining.cpp:18
  in /home/milian/projects/build/heaptrack/tests/manual/inlining

Afterwards, we get all frames:

1 calls to allocation functions with 1.23KB peak consumption from
asdf()
  at /home/milian/projects/src/heaptrack/tests/manual/inlining.cpp:3
  in /home/milian/projects/build/heaptrack/tests/manual/inlining
bar()
  at /home/milian/projects/src/heaptrack/tests/manual/inlining.cpp:8
foo()
  at /home/milian/projects/src/heaptrack/tests/manual/inlining.cpp:13
main
  at /home/milian/projects/src/heaptrack/tests/manual/inlining.cpp:18

Do not clear flamegraph on hide

This way we keep the history / zoom state when navigating away from
the flamegraph, e.g. to quickly check something in the caller/callee
view.

Force the fill method to never get inlined