From 76c10fe9f4ae90124e1987ea8dfe9af164d23fd1 Mon Sep 17 00:00:00 2001
From: tth <sigfood@dinorama.fr>
Date: Wed, 25 Nov 2020 11:29:26 +0100
Subject: [PATCH] bonaldi !!!

---
 chap/debug.tex | 68 +++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 62 insertions(+), 6 deletions(-)

diff --git a/chap/debug.tex b/chap/debug.tex
index c9b3e12..df7e50e 100644
--- a/chap/debug.tex
+++ b/chap/debug.tex
@@ -5,7 +5,8 @@ Quand plus rien ne marche, reste-il encore un espoir ?
 Il existe bien entendu des outils \textsl{mainstream}
 tels que le classique \texttt{gdb}\index{gdb}, mais il en existe
 une foultitude d'autres, injustement méconnus.
-Nous allons en voir quelques-uns.
+Nous allons en voir quelques-uns en essayant de nous baser
+sur des cas réels.
 
 % ==============================================================
 
@@ -18,18 +19,73 @@ where errors occurred. Currently, gdb supports C, C++, D,
 Objective-C, Fortran, Java, OpenCL C, Pascal, assembly, Modula-2,
 Go, and Ada. \textsc{A must-have for any serious programmer}.
 
-\subsection{ddd}
+\subsection{Clickaconvi}
 
-DDD is a graphical front-end for GDB and other command-line  debuggers.
+\textbf{DDD} is a graphical front-end for GDB and other command-line  debuggers.
 Using DDD, you can see what is going on “inside” another program while
 it executes—or what another program was doing at the moment it crashed.
 
-\subsection{xxgdb}
-
-xxgdb is a simple but powerful graphical interface to the GNU
+\textbf{xxgdb} is a simple but powerful graphical interface to the GNU
 debugger gdb.  A more powerful (but slower and much bigger) interface
 is available in the ddd package.
 
+% --------------------------------------------------
+% novembre 2020, panique dans le kernel de la Fedora
+%
+\subsection{Un cas réel}
+
+J'ai un programme, écrit en C, qui est assez agressif sur
+le calcul flottant et les accès disque,
+et qui se fait tuer en cours de route,
+avec un message inquiétant du kernel
+\texttt{[95335.731943] fonderie: Corrupted page table at address
+7fffe82d6000} qui me laisse perplexe.
+
+
+\begin{verbatim}
+[tth@laserbox Sauvageonnes]$ gdb ~/Devel/FloatImg/Fonderie/fonderie
+GNU gdb (GDB) Fedora 10.1-2.fc33
+This GDB was configured as "x86_64-redhat-linux-gnu".
+Reading symbols from /home/tth/Devel/FloatImg/Fonderie/fonderie...
+(gdb) run -I 'G/?????.fimg' -O 'Png' -w 0 -x 0 -T 80
+Starting program:
+            /home/tth/Devel/FloatImg/Fonderie/fonderie
+            -I 'G/?????.fimg' -O 'Png' -w 0 -x 0 -T 80
+Missing separate debuginfos, use:
+            dnf debuginfo-install glibc-2.32-2.fc33.x86_64
+*** /home/tth/Devel/FloatImg/Fonderie/fonderie :
+        compiled by tTh, Nov 25 2020 10:19:10
+        pid 1949
+\end{verbatim}
+
+Là, on attend vingt minutes que le logiciel tripote plein 
+d'images en virgule flottante. C'est long.
+
+\begin{verbatim}
+           54 /  1784
+Program terminated with signal SIGKILL, Killed.
+The program no longer exists.
+Missing separate debuginfos, use:
+            dnf debuginfo-install pnglite-0.1.17-1.fc33.21.x86_64
+            zlib-1.2.11-22.fc33.x86_64
+(gdb)
+\end{verbatim}
+
+On est donc bien avancé, \texttt{SIGKILL}, dans ce cas-là,
+c'est le noyau qui flingue\index{bfg9000} le processus.
+Mais pour quelle raison, et à quel endroit dans le programme ?
+Avec un peu de chance, gdb a conservé une trace des dernières
+microscondes de la fonderie.
+
+\begin{verbatim}
+(gdb) backtrace 
+No stack.
+(gdb)
+\end{verbatim}
+
+Bah non, il nous avait bien prévenu :
+\textit{The program no longer exists}, point suivant.
+
 % ==============================================================
 
 \section{Strace}\index{strace}