bonaldi !!!

This commit is contained in:
tth 2020-11-25 11:29:26 +01:00
parent 958a1b7152
commit 76c10fe9f4

View File

@ -5,7 +5,8 @@ Quand plus rien ne marche, reste-il encore un espoir ?
Il existe bien entendu des outils \textsl{mainstream} Il existe bien entendu des outils \textsl{mainstream}
tels que le classique \texttt{gdb}\index{gdb}, mais il en existe tels que le classique \texttt{gdb}\index{gdb}, mais il en existe
une foultitude d'autres, injustement méconnus. 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, Objective-C, Fortran, Java, OpenCL C, Pascal, assembly, Modula-2,
Go, and Ada. \textsc{A must-have for any serious programmer}. 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 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. it executes—or what another program was doing at the moment it crashed.
\subsection{xxgdb} \textbf{xxgdb} is a simple but powerful graphical interface to the GNU
xxgdb is a simple but powerful graphical interface to the GNU
debugger gdb. A more powerful (but slower and much bigger) interface debugger gdb. A more powerful (but slower and much bigger) interface
is available in the ddd package. 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} \section{Strace}\index{strace}