/usr/share/help/sv/sysprof/faq.page is in sysprof 3.28.1-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 | <?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="faq" xml:lang="sv">
<info>
<link type="guide" xref="index#faq"/>
<mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
<mal:name>Anders Jonsson</mal:name>
<mal:email>anders.jonsson@norsjovallen.se</mal:email>
<mal:years>2016</mal:years>
</mal:credit>
</info>
<title>What does heap mean?</title>
<section id="what-does-heap-mean">
<title>What does "In file [heap]" mean?</title>
<p>This means that sysprof believes a function was called from somewhere in
the program's heap (where <code>malloc</code> allocates memory) rather than
the code section (where executable code normally lives.) There are several
possible explanations.
</p>
</section>
<section id="jit">
<title>JIT (Just in Time) compilers</title>
<p>Languages like Java can generate executable code while a program is
running and store it in the heap. Sysprof is accurately reporting the
situation in this case.</p>
</section>
<section id="optimizing">
<title>Optimizing compilers</title>
<p>C and C++ compilers can optimize away information needed to determine a
function's caller, so it is mistaken for [heap]. You can still tell how
often each function is called by the program, but not always from
where.</p>
<note>
<p>For gcc, the flag <code>-fno-omit-frame-pointer</code> will prevent
this optimization. The flag is not always needed, for example on x86_64
machines it is only needed with -O3 optimization.</p>
</note>
<note>
<p>To get the most detailed and accurate call tree from un-optimized
code, use these flags: <code>-ggdb -fno-omit-frame-pointer -O0</code></p>
</note>
</section>
</page>
|