[bootlin/training-materials updates] master: debugging: move Massif labs from memory issues to application profiling (18714702)

Clément Léger clement.leger at bootlin.com
Wed Nov 16 09:54:42 CET 2022


Repository : https://github.com/bootlin/training-materials
On branch  : master
Link       : https://github.com/bootlin/training-materials/commit/1871470224c2332962b91bac3b6d80b783134dde

>---------------------------------------------------------------

commit 1871470224c2332962b91bac3b6d80b783134dde
Author: Clément Léger <clement.leger at bootlin.com>
Date:   Wed Nov 16 09:55:09 2022 +0100

    debugging: move Massif labs from memory issues to application profiling
    
    Signed-off-by: Clément Léger <clement.leger at bootlin.com>


>---------------------------------------------------------------

1871470224c2332962b91bac3b6d80b783134dde
 .../debugging-application-profiling.tex            | 35 ++++++++++++++++++++++
 .../debugging-memory-issues.tex                    | 35 ----------------------
 .../debugging-application-tracing.tex              |  6 ++--
 .../debugging-memory-issues.tex                    |  1 -
 4 files changed, 38 insertions(+), 39 deletions(-)

diff --git a/labs/debugging-application-profiling/debugging-application-profiling.tex b/labs/debugging-application-profiling/debugging-application-profiling.tex
index fbf7a5cd..307bad23 100644
--- a/labs/debugging-application-profiling/debugging-application-profiling.tex
+++ b/labs/debugging-application-profiling/debugging-application-profiling.tex
@@ -2,12 +2,47 @@
 {Application profiling}
 {Objectives:
   \begin{itemize}
+    \item Visualizing application heap using {\em Massif}.
     \item Profiling an application with {\em Cachegrind}, {\em Callgrind} and
           {\em KCachegrind}.
     \item Analyzing application performances with {\em perf}.
   \end{itemize}
 }
 
+\section{Massif}
+
+Massif is really helpful to understand what is going on the memory allocation
+side of an application. Compile the \code{heap_profile} example that we did provide
+using the following command:
+
+\begin{bashinput}
+$ cd /home/<user>/debugging-labs/nfsroot/root/heap_profile
+$ ${CROSS_COMPILE}-gcc -g3 heap_profile.c -o heap_profile
+\end{bashinput}
+
+Once compile, on the target run it under massif using the following command:
+
+\begin{bashinput}
+$ cd /root/heap_profile
+$ valgrind --tool=massif --time-unit=B ./heap_profile
+\end{bashinput}
+
+NOTE: we use \code{--time-unit=B} to set the X axis to be based on the allocated
+size.
+
+Once done, a \code{massif.out.<pid>} file will be created. This file can be
+displayed with \code{ms_print}. Based on the result, can you answer the
+following questions:
+\begin{itemize}
+  \item What is the peak allocation size of this program ?
+  \item How much memory was allocated during the program lifetime ?
+  \item Do we have memory leaks at the end of execution ?
+\end{itemize}
+
+Note: \code{heaptrack} is not available on buildroot but is available on debian.
+You can try the same experience using heaptrack on your computer and visualizing
+the results with \code{heaptrack_gui}.
+
 \section{Cachegrind \& Callgrind}
 
 Cachegrind and Callgrind allows to profile a userspace application by
diff --git a/labs/debugging-memory-issues/debugging-memory-issues.tex b/labs/debugging-memory-issues/debugging-memory-issues.tex
index 003e52c6..64fb3084 100644
--- a/labs/debugging-memory-issues/debugging-memory-issues.tex
+++ b/labs/debugging-memory-issues/debugging-memory-issues.tex
@@ -4,7 +4,6 @@
   \begin{itemize}
     \item Memory leak and misbehavior detection with {\em valgrind} and
             {\em vgdb}.
-    \item Visualizing application heap using {\em Massif}.
   \end{itemize}
 }
 
@@ -69,37 +68,3 @@ were encountered by valgrind.
 NOTE: The backtrace for leaks is not shown on the target because all libraries
 are stripped and thus do not have any debugging symbols anymore. This leads to
 the impossibility to use the dwarf information for backtracing.
-
-\section{Massif}
-
-Massif is really helpful to understand what is going on the memory allocation
-side of an application. Compile the \code{heap_profile} example that we did provide
-using the following command:
-
-\begin{bashinput}
-$ cd /home/<user>/debugging-labs/nfsroot/root/heap_profile
-$ ${CROSS_COMPILE}-gcc -g3 heap_profile.c -o heap_profile
-\end{bashinput}
-
-Once compile, on the target run it under massif using the following command:
-
-\begin{bashinput}
-$ cd /root/heap_profile
-$ valgrind --tool=massif --time-unit=B ./heap_profile
-\end{bashinput}
-
-NOTE: we use \code{--time-unit=B} to set the X axis to be based on the allocated
-size.
-
-Once done, a \code{massif.out.<pid>} file will be created. This file can be 
-displayed with \code{ms_print}. Based on the result, can you answer the
-following questions:
-\begin{itemize}
-  \item What is the peak allocation size of this program ?
-  \item How much memory was allocated during the program lifetime ?
-  \item Do we have memory leaks at the end of execution ?
-\end{itemize}
-
-Note: \code{heaptrack} is not available on buildroot but is available on debian.
-You can try the same experience using heaptrack on your computer and visualizing
-the results with \code{heaptrack_gui}.
\ No newline at end of file
diff --git a/slides/debugging-application-tracing/debugging-application-tracing.tex b/slides/debugging-application-tracing/debugging-application-tracing.tex
index 42f09bda..192e7e90 100644
--- a/slides/debugging-application-tracing/debugging-application-tracing.tex
+++ b/slides/debugging-application-tracing/debugging-application-tracing.tex
@@ -68,7 +68,6 @@ $ LD_PRELOAD=my_lib.so ./exe
   \end{itemize}
 \end{frame}
 
-
 \begin{frame}[fragile]
   \frametitle{The {\em perf} tool}
   \begin{itemize}
@@ -129,7 +128,8 @@ $ perf record -e probe_app:my_func,probe_libc:printf
 {
   Analyzing of application interactions
   \begin{itemize}
-    \item Tracing system calls with {\em strace}
-    \item Analyze dynamic library calls
+    \item Analyze dynamic library calls from an application using
+            {\em ltrace}.
+    \item Using {\em strace} to analyze program syscalls.
   \end{itemize}
 }
\ No newline at end of file
diff --git a/slides/debugging-memory-issues/debugging-memory-issues.tex b/slides/debugging-memory-issues/debugging-memory-issues.tex
index 1fd85d31..1c0d5fbe 100644
--- a/slides/debugging-memory-issues/debugging-memory-issues.tex
+++ b/slides/debugging-memory-issues/debugging-memory-issues.tex
@@ -275,6 +275,5 @@ Program terminated with signal SIGSEGV, Segmentation fault.
   \begin{itemize}
     \item Memory leak and misbehavior detection with {\em valgrind} and
             {\em vgdb}.
-    \item Visualizing application heap using {\em Massif}.
   \end{itemize}
 }
\ No newline at end of file




More information about the training-materials-updates mailing list