| 1 |
nimiux 10/06/28 17:30:49 |
| 2 |
|
| 3 |
Added: backtraces.xml |
| 4 |
Log: |
| 5 |
New spanish tranlation. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.1 xml/htdocs/proj/es/qa/backtraces.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/qa/backtraces.xml?rev=1.1&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/es/qa/backtraces.xml?rev=1.1&content-type=text/plain |
| 12 |
|
| 13 |
Index: backtraces.xml |
| 14 |
=================================================================== |
| 15 |
<?xml version="1.0" encoding="utf-8"?> |
| 16 |
<!DOCTYPE guide SYSTEM "http://www.gentoo.org/dtd/guide.dtd"> |
| 17 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/es/qa/backtraces.xml,v 1.1 2010/06/28 17:30:49 nimiux Exp $ --> |
| 18 |
|
| 19 |
|
| 20 |
<guide link="/proj/en/qa/backtraces.xml" lang="en"> |
| 21 |
<title>Cómo obtener trazas íntegras en Gentoo</title> |
| 22 |
|
| 23 |
<author title="Autor"> |
| 24 |
<mail link="flameeyes@g.o">Diego E. Pettenò</mail> |
| 25 |
</author> |
| 26 |
|
| 27 |
<author title="Información sobre la cadena de herramientas Hardened"> |
| 28 |
<mail link="solar@g.o">Ned Ludd</mail> |
| 29 |
</author> |
| 30 |
|
| 31 |
<author title="Información sobre la cadena de herramientas Hardened y la arquitectura x86"> |
| 32 |
<mail link="kevquinn@g.o">Kevin Quinn</mail> |
| 33 |
</author> |
| 34 |
|
| 35 |
<author title="Revisor"> |
| 36 |
<mail link="dberkholz@g.o">Donnie Berkholz</mail> |
| 37 |
</author> |
| 38 |
|
| 39 |
<abstract> |
| 40 |
Esta guía pretende ofrecer a los usuarios una explicación simple de porqué |
| 41 |
una instalación por defecto de Gentoo no ofrece unas trazas íntegras y cómo |
| 42 |
realizar ajustes para obtenerlas. |
| 43 |
</abstract> |
| 44 |
|
| 45 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 46 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 47 |
|
| 48 |
|
| 49 |
<license/> |
| 50 |
|
| 51 |
<version>0.10</version> |
| 52 |
<date>2010-06-16</date> |
| 53 |
|
| 54 |
<chapter><!-- Introduction --> |
| 55 |
|
| 56 |
<title>Trazas en Gentoo</title> |
| 57 |
|
| 58 |
<section> |
| 59 |
<title>¿Qué son las trazas?</title> |
| 60 |
|
| 61 |
<body> |
| 62 |
|
| 63 |
<p> |
| 64 |
Una <e>traza</e>, también llamada bt, trace, o stack trace (traza de pila) |
| 65 |
es un informe legible por un humano de la pila de llamadas realizadas por un |
| 66 |
programa. Informa en qué punto de un programa se encuentra y cómo se llegó |
| 67 |
a ese punto a través de todas las funciones hasta la función |
| 68 |
<path>main()</path> (por lo menos esta es la teoría). Las trazas son |
| 69 |
normalmente analizadas cuando acontecen condiciones de error como fallos de |
| 70 |
segmento o abortos en la ejecución. Para su análisis se usan depuradores |
| 71 |
como <c>gdb</c> (GNU debugger), que ayudan a encontrar la causa del error. |
| 72 |
</p> |
| 73 |
|
| 74 |
<p> |
| 75 |
Una traza íntegra, contiene no sólo los objetos compartidos (shared objects) |
| 76 |
en los que se generó la llamada, también el nombre de la función, el nombre |
| 77 |
del fichero y el la línea en la que se detuvo la ejecución. Desgraciadamente |
| 78 |
en un sistema optimizado para el rendimiento y el ahorro de espacio, las |
| 79 |
trazas no tienen ninguna utilidad y muestran únicamente los punteros a la |
| 80 |
pila y una serie de caracteres ?? en lugar del nombre de las funciones y su |
| 81 |
posición. |
| 82 |
</p> |
| 83 |
|
| 84 |
<p> |
| 85 |
Esta guía le mostrará cómo es posible obtener trazas útiles e íntegras en |
| 86 |
Gentoo usando características de Portage. |
| 87 |
</p> |
| 88 |
|
| 89 |
</body> |
| 90 |
</section> |
| 91 |
|
| 92 |
<section><!-- Compiler flags --> |
| 93 |
|
| 94 |
<title>Ajustes del compilador</title> |
| 95 |
|
| 96 |
<body> |
| 97 |
|
| 98 |
<p> |
| 99 |
Por defecto <c>gcc</c> no incluye información de depuración dentro de los |
| 100 |
objetos (librerías y programas) que construye, ya que ésto crearía objetos |
| 101 |
más grandes. También muchas optimizaciones interfieren en cómo la |
| 102 |
información de depuración es guardada. Por estas razones, la primera |
| 103 |
cuestión a tener en cuenta es que los ajustes CFLAGS estén preparados para |
| 104 |
generar información de depuración útil. |
| 105 |
</p> |
| 106 |
|
| 107 |
<p> |
| 108 |
El ajuste básico a añadir en este caso es <c>-g</c>. Ésto hace que el |
| 109 |
compilador incluya información extra en los objetos, como los nombres de |
| 110 |
fichero y los números de línea. Esto normalmente es suficiente para tener |
| 111 |
trazas básicas. Sin embargo el ajuste <c>-ggdb</c> añade más información. De |
| 112 |
hecho existe otro ajuste (<c>-g3</c>) pero su uso no está |
| 113 |
recomendado. Parece que rompe las interfaces binarias y puede llevar a algún |
| 114 |
error de ejecución inesperado. Por ejemplo <path>glibc</path> falla cuando |
| 115 |
se construye usando este ajuste. Si quiere ofrecer la mayor información |
| 116 |
posible, debe usar el ajuste <c>-ggdb</c>. |
| 117 |
</p> |
| 118 |
|
| 119 |
<pre caption="Ejemplo de CFLAGS con información de depuración"> |
| 120 |
CFLAGS="-march=k8 -O2 -ggdb" |
| 121 |
CXXFLAGS="${CFLAGS}" |
| 122 |
</pre> |
| 123 |
|
| 124 |
<p> |
| 125 |
Altos niveles de optimización como <c>-O3</c> pueden causar que la traza sea |
| 126 |
menos fiable o incluso incorrecta. Generalmente hablando, <c>-O2</c> y |
| 127 |
<c>-Os</c> pueden usarse de forma segura para obtener una traza aproximada, |
| 128 |
bajando hasta la función llamada y el área del fichero fuente dónde se |
| 129 |
produjo el error de ejecución. Para trazas más precisas se puede usar |
| 130 |
<c>-O1</c>. |
| 131 |
</p> |
| 132 |
|
| 133 |
<note> |
| 134 |
El uso de <c>-O0</c> es sugerido a menudo cuando se intenta producir una |
| 135 |
traza completa. Desgraciadamente esto no funciona siempre bien con el |
| 136 |
software, ya que la desactivación de las optimizaciones cambia la |
| 137 |
implementación de las funciones en la librería GNU C (sys-libs/glibc), hasta |
| 138 |
el punto de que se pueden considerar dos librerías diferentes, una para |
| 139 |
construcciones optimizadas y otra para no optimizadas. También, algún |
| 140 |
software puede fallar a la hora de ser construido cuando se usa <c>-O0</c>, |
| 141 |
debido a los cambios en los ficheros de inclusión de cabeceras y la falta de |
| 142 |
características como la propagación constante en la eliminación de código |
| 143 |
muerto. |
| 144 |
</note> |
| 145 |
|
| 146 |
<p> |
| 147 |
Aviso para los usuarios de arquitecturas x86: Los usuarios de x86 |
| 148 |
normalmente tienen <c>-fomit-frame-pointer</c> en su CFLAGS. La arquitectura |
| 149 |
x86 tiene un juego limitado de registros generales, y este ajuste puede |
| 150 |
hacer que esté disponible un nuevo registro que mejora el rendimiento. Sin |
| 151 |
embargo, esto tiene un coste: hace imposible a <c>gdb</c> "caminar por la |
| 152 |
pila" — en otras palabras: generar la traza de forma |
| 153 |
confiable. Elimine este ajuste de CFLAGS para construir algo más fácil de |
| 154 |
comprender para <c>gdb</c>. En otras plataformas no hay que preocuparse por |
| 155 |
esto; generalmente el ajuste <c>-fomit-frame-pointer</c> no está activado, o |
| 156 |
el código generado por <c>gcc</c> no confunde a <c>gdb</c> (en cuyo caso el |
| 157 |
ajuste está activado por el nivel de optimización <c>-O2</c>). |
| 158 |
</p> |
| 159 |
|
| 160 |
<p> |
| 161 |
Los usuarios de hardened tienen otras cosas de las que preocuparse. Las <uri |
| 162 |
link="http://www.gentoo.org/proj/en/hardened/hardenedfaq.xml#hardeneddebug"> |
| 163 |
Preguntas de Uso Frecuente de Gentoo Hardened</uri> ofrecen consejos y |
| 164 |
trucos extra que necesitará saber. |
| 165 |
</p> |
| 166 |
|
| 167 |
</body> |
| 168 |
</section> |
| 169 |
|
| 170 |
<section><!-- Stripping --> |
| 171 |
|
| 172 |
<title>Recortando (haciendo stripping)</title> |
| 173 |
|
| 174 |
<body> |
| 175 |
<p> |
| 176 |
Simplemente cambiando sus CFLAGS y haciendo emerge world de nuevo no le dará |
| 177 |
trazas íntegras, ya que tiene que solventar el problema del recorte. Por |
| 178 |
defecto Portage recorta los binarios que genera. En otras palabras, elimina |
| 179 |
las secciones innecesarias para el funcionamiento reduciendo el tamaño de |
| 180 |
los ficheros instalados. Esto es bueno para el usuario medio, el cual no |
| 181 |
necesita generar trazas, sin embargo, elimina toda la información de |
| 182 |
depuración generada por los ajustes <c>-g*</c> al igual que las tablas de |
| 183 |
símbolos que son necesarias para encontrar la información base para mostrar |
| 184 |
las trazas de una forma legible por los humanos. |
| 185 |
</p> |
| 186 |
|
| 187 |
<p> |
| 188 |
Hay dos formas de hacer que el recorte no afecte a la depuración y a la |
| 189 |
generación de trazas. En primer lugar, se debe indicar a Portage que no |
| 190 |
recorte binarios de ningún modo, añadiendo <e>nostrip</e> a FEATURES. Esto |
| 191 |
dejará instalados los ficheros exactamante donde <c>gcc</c> los creó, con |
| 192 |
toda la información de depuración y las tablas de símbolos, lo cual |
| 193 |
incrementa el espacio en disco ocupado por los ejecutables y las |
| 194 |
librerías. Para evitar este problema, en la versión 2.0.54-r1 uy en las |
| 195 |
series 2.1 de Portage, es posible usar la FEATURE <e>splitdebug</e> en su |
| 196 |
lugar. |
| 197 |
</p> |
| 198 |
|
| 199 |
<p> |
| 200 |
Con <e>splitdebug</e> activado, Portage recortará los binarios instalados en |
| 201 |
el sistema. Pero antes de hacer esto, toda la información de depuración que |
| 202 |
sea de utilidad es copiada al fichero ".debug", que es luego instalado |
| 203 |
dentro de <path>/usr/lib/debug</path> (el nombre completo del fichero se |
| 204 |
obtendría añadiendo a éste el camino donde el fichero es instalado |
| 205 |
realmente). El camino a este fichero es entonces guardado en el fichero |
| 206 |
original dentro de una sección ELF llamada ".gnu_debuglink", de modo que |
| 207 |
<c>gdb</c> sepa desde que fichero tiene que cargar los símbolos. |
| 208 |
</p> |
| 209 |
|
| 210 |
<impo> |
| 211 |
Si se activan ambas características <e>nostrip</e> y <e>splitdebug</e>, |
| 212 |
Portage no recortará los binarios de ninguna forma, de modo que se debe que |
| 213 |
prestar especial atención a lo que se quiere hacer. |
| 214 |
</impo> |
| 215 |
|
| 216 |
<p> |
| 217 |
Otra ventaja de <e>splitdebug</e> es que no requiere la reconstrucción de |
| 218 |
los paquetes para deshacerse de la información de depuración. Esto es útil |
| 219 |
cuando se construyen algunos paquetes con depuración para obtener una traza |
| 220 |
de un sólo error. Una vez este error está subsanado, simplemente se necesita |
| 221 |
eliminar el directorio <path>/usr/lib/debug</path>. |
| 222 |
</p> |
| 223 |
|
| 224 |
<p> |
| 225 |
Para asegurarse de que no se recortan los binarios, deberá también |
| 226 |
asegurarse de que tiene activado el ajuste <c>-s</c> en su LDFLAGS. Esto le |
| 227 |
indica al enlazador que debe recortar los binarios resultantes en la fase de |
| 228 |
enlazado. También note que usando este ajuste puede desembocar en problemas |
| 229 |
futuros. No se respetarán las restricciones impuestas por algunos paquetes |
| 230 |
que dejan de funcionar cuando son recortados completamente. |
| 231 |
</p> |
| 232 |
|
| 233 |
<note> |
| 234 |
Algunos paquetes desafortunadamente manejan el recorte por sí mismos, dentro |
| 235 |
de los ficheros makefile suministrados por el equipo de desarrollo. Esto es |
| 236 |
un error y debe ser notificado. Todos los paquetes deben dejar a Portage la |
| 237 |
tarea de hacer el recorte, o no permitir el recorte de ningún modo. La |
| 238 |
principal excepción a esto son los paquetes binarios. Son normalmente |
| 239 |
recortados por el equipo de desarrollo del paquete fuera del control de |
| 240 |
Portage. |
| 241 |
</note> |
| 242 |
|
| 243 |
</body> |
| 244 |
|
| 245 |
</section> |
| 246 |
|
| 247 |
<section><!-- debug USE flag --> |
| 248 |
|
| 249 |
<title>Ajuste USE debug</title> |
| 250 |
|
| 251 |
<body> |
| 252 |
|
| 253 |
<p> |
| 254 |
Algunos ebuild proporcionan un ajuste USE <b>debug</b>. Aunque algunos lo |
| 255 |
usan de forma incorrecta para ofrecer información de depuración y juegan con |
| 256 |
los ajustes del compilador cuando el ajuste está activado, éste no es su |
| 257 |
propósito. |
| 258 |
</p> |
| 259 |
|
| 260 |
<p> |
| 261 |
Si está tratando de depurar un error de ejecución que se puede reproducir, |
| 262 |
se deberá dejar sólo este ajuste USE, ya que estará construyendo una fuente |
| 263 |
diferente de la que tenía previamente. Es más eficiente obtener en primer |
| 264 |
lugar una traza sin cambiar el código, simplemente omitiendo la información |
| 265 |
de símbolos y justo después de activar las características de depuración |
| 266 |
para hacer un seguimiento del problema más adelante. |
| 267 |
</p> |
| 268 |
|
| 269 |
<p> |
| 270 |
La características de depuración son activadas mediante las aserciones en |
| 271 |
los ficheros de cabecera, registros de depuración en la pantalla, ficheros |
| 272 |
de depuración, detección de goteras (leaks) y operaciones con seguridad |
| 273 |
extra (como por ejemplo la limpieza de memoria antes de su uso). Algunos |
| 274 |
pueden ser complicados, especialmente en software complejo o en el cual el |
| 275 |
rendimiento es una cuestión importante. |
| 276 |
</p> |
| 277 |
|
| 278 |
<p> |
| 279 |
Por estas razones, por favor, tenga cuidado cuando active el ajuste USE |
| 280 |
<b>debug</b>, y considérelo como el último recurso. |
| 281 |
</p> |
| 282 |
|
| 283 |
</body> |
| 284 |
|
| 285 |
</section> |
| 286 |
|
| 287 |
<section><!-- Introducing gdb --> |
| 288 |
|
| 289 |
<title>Introducción a gdb</title> |
| 290 |
|
| 291 |
<body> |
| 292 |
|
| 293 |
<p> |
| 294 |
Una vez construidos los paquetes con información de depuración y no son |
| 295 |
recortados, simplemente necesita obtener la traza. Para ello, necesitará el |
| 296 |
paquete <path>sys-devel/gdb</path>. Contiene el depurador GNU |
| 297 |
(<c>gdb</c>). Después de instalarlo, podrá obtener la traza. La forma más |
| 298 |
simple de obtnerla es ejecutar el programa dentro de <c>gdb</c>. Para ello, |
| 299 |
necesitará apuntar <c>gdb</c> al camino del programa a ejecutar, darle los |
| 300 |
argumentos que necesite y ejecutarlo: |
| 301 |
</p> |
| 302 |
|
| 303 |
<pre caption="Corriendo ls a través de gdb"> |
| 304 |
$ <i>gdb /bin/ls</i> |
| 305 |
GNU gdb 6.4 |
| 306 |
[...] |
| 307 |
|
| 308 |
(gdb) <i>set args /usr/share/fonts</i> |
| 309 |
(gdb) <i>run</i> |
| 310 |
Starting program: /bin/ls /usr/share/fonts |
| 311 |
[Thread debugging using libthread_db enabled] |
| 312 |
[New Thread 47467411020832 (LWP 11100)] |
| 313 |
100dpi aquafont baekmuk-fonts cyrillic dejavu fonts.cache-1 kochi-substitute misc xdtv |
| 314 |
75dpi arphicfonts CID default encodings fonts.dir mikachan-font util |
| 315 |
|
| 316 |
Program exited normally. |
| 317 |
(gdb) |
| 318 |
</pre> |
| 319 |
|
| 320 |
<p> |
| 321 |
El mensaje "Program exited normally" (el programa terminó correctamente), |
| 322 |
indica que el programa acabó devolviendo el código de salida 0. Esto |
| 323 |
significa que no se produjo ningún error. No debe fiarse mucho de esto ya |
| 324 |
que hay programas que devuelven 0 cuando alcanzan una condición de |
| 325 |
error. Otro mensaje común es "Program exited with code <e>nn</e>" (el |
| 326 |
programa terminó con código <e>nn</e>). Esto simplemente le indica que |
| 327 |
código de estado distinto de cero ha devuelto el programa. Esto puede |
| 328 |
implicar una condición de error manejada o esperada. Para fallos de segmento |
| 329 |
y abortos en la ejecución puede que obtenga el mensaje "Program received |
| 330 |
signal SIGsomething" (el programa recibió la señal SIGalgo). |
| 331 |
</p> |
| 332 |
|
| 333 |
<p> |
| 334 |
Cuando un programa recibe una señal, puede ser por varias razones. En el |
| 335 |
caso de SIGSEGV y SIGABRT (fallo de segmento y aborto en la ejecución |
| 336 |
respectivamente), normalmente significa que el código está haciendo algo |
| 337 |
incorrecto como una llamada al sistema inválida o acceder a memoria a través |
| 338 |
de un puntero roto. Otras señales comunes son: SIGTERM, SIGQUIT y SIGINT (la |
| 339 |
última se recibe cuando se envía CTRL-C al programa y normalmente es |
| 340 |
capturada por <c>gdb</c> e ignorada por el programa). |
| 341 |
</p> |
| 342 |
|
| 343 |
<p> |
| 344 |
Finalmente hay una serie de "Eventos de tiempo real". Se nombran como |
| 345 |
SIG<e>nn</e> siendo <e>nn</e> un número mayor que 31. La implementación |
| 346 |
pthread normalmente usa estos eventos para sincronizar los diferentes hilos |
| 347 |
del programa, y así no se presentan condiciones de error de ningún tipo. Es |
| 348 |
fácil ofrecer trazas sin sentido cuando se confunden las señales de tiempo |
| 349 |
real con las condiciones de error. Para evitar esto, puede indicar a |
| 350 |
<c>gdb</c> que no pare cuando éstas se reciben, y en lugar de ésto, pasarlas |
| 351 |
directamente al programa como en el ejemplo siguiente. |
| 352 |
</p> |
| 353 |
|
| 354 |
<pre caption="Corriendo xine-ui a través de gdb, ignorando las señales de tiempo real."> |
| 355 |
$ <i>gdb /usr/bin/xine</i> |
| 356 |
GNU gdb 6.4 |
| 357 |
[...] |
| 358 |
|
| 359 |
(gdb) <i>run</i> |
| 360 |
Starting program: /usr/bin/xine |
| 361 |
[...] |
| 362 |
|
| 363 |
Program received signal SIG33, Real-time event 33. |
| 364 |
[Switching to Thread 1182845264 (LWP 11543)] |
| 365 |
0x00002b661d87d536 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 |
| 366 |
(gdb) <i>handle SIG33 nostop noprint noignore pass</i> |
| 367 |
Signal Stop Print Pass to program Description |
| 368 |
SIG33 No No Yes Real-time event 33 |
| 369 |
(gdb) <i>kill</i> |
| 370 |
Kill the program being debugged? (y or n) <i>y</i> |
| 371 |
(gdb) <i>run</i> |
| 372 |
</pre> |
| 373 |
|
| 374 |
<p> |
| 375 |
El comando <c>handle</c> indica a <c>gdb</c> qué debe hacer cuando la señal |
| 376 |
dada es enviada al programa; en este caso los ajustes son <c>nostop</c> (no |
| 377 |
parar el programa, devolviendo el comando al depurador), <c>noprint</c> (no |
| 378 |
molestarse en imprimir la recepción de la señal recibida), <c>noignore</c> |
| 379 |
(no ignorar la señal — ignorar señales es peligroso, ya que implica |
| 380 |
descartarlas sin pasarlas al programa), <c>pass</c> (pasar las señal al |
| 381 |
programa en depuración). |
| 382 |
</p> |
| 383 |
|
| 384 |
<p> |
| 385 |
Después de que los eventuales eventos en tiempo real son ignorados por |
| 386 |
<c>gdb</c>, deberá intentar reproducir el error que desea reportar. si lo |
| 387 |
puede reproducir de forma sistemática, entonces es muy fácil. Cuando |
| 388 |
<c>gdb</c> indica que el programa ha recibido las señales SIGSEGV o SIGABRT |
| 389 |
(o cualquier otra señal que pueda representar una condición de error en el |
| 390 |
programa), tendrá que generar la traza, posiblemente guardándola en algún |
| 391 |
lugar. El comando básico para hacerlo es <c>bt</c>, que es la abreviatura de |
| 392 |
<c>backtrace</c>, este comando muestra la traza del hilo de ejecución actual |
| 393 |
(si el programa tiene un solo hilo, entonces hay un solo hilo de ejecución). |
| 394 |
</p> |
| 395 |
|
| 396 |
<p> |
| 397 |
Un comando alternativo para obtener una traza más detallada es <c>bt |
| 398 |
full</c>. Este comando ofrece información sobre parámetros y variables |
| 399 |
locales de la función en la que las llamadas son realizadas (siempre que |
| 400 |
estén disponibles y no hayan sido eliminadas por el uso de |
| 401 |
optimizaciones). Esto hace que la traza sea más larga, pero más útil a la |
| 402 |
hora de encontrar, por ejemplo, porqué un puntero no se ha inicializado. |
| 403 |
</p> |
| 404 |
|
| 405 |
<p> |
| 406 |
Finalmente, no es extraño que incluso los programas más simples sean |
| 407 |
escritos con múltiples hilos de ejecución. En estos casos usar la salida de |
| 408 |
un simple <c>bt</c>, aunque tiene sentido, no tiene ninguna utilidad, ya que |
| 409 |
puede representar el estado de un hilo de ejecución diferente al hilo en el |
| 410 |
que se ha generado la señal o en el que la condición de error se ha |
| 411 |
manifestado (en caso que haya otro hilo responsable de generar señales). Por |
| 412 |
esta razón, debe en su lugar obtener la traza con el comando <c>thread apply |
| 413 |
all bt full</c> (más largo), que indica a la depuración que imprima la traza |
| 414 |
completa de todos los hilos que se estén ejecutando en ese momento. |
| 415 |
</p> |
| 416 |
|
| 417 |
<p> |
| 418 |
Si la traza es corta, es fácil copiar y pegarla fuera del terminal (a menos |
| 419 |
que el fallo suceda en un terminal sin X). En la mayoría de los casos es tan |
| 420 |
larga que no puede ser copiada fácilmente ya que se extiende a través de |
| 421 |
varias páginas. Para poder obtener trazas en un fichero con la intención de |
| 422 |
adjuntarlo a un informe de error, se debe usar la característica |
| 423 |
<c>logging</c>: |
| 424 |
</p> |
| 425 |
|
| 426 |
<pre caption="Usando la característica logging para guardar la traza a un fichero."> |
| 427 |
$ <i>gdb /usr/bin/xine</i> |
| 428 |
GNU gdb 6.5 |
| 429 |
[...] |
| 430 |
|
| 431 |
(gdb) <i>run</i> |
| 432 |
[...] |
| 433 |
|
| 434 |
(gdb) <i>set logging file backtrace.log</i> |
| 435 |
(gdb) <i>set logging on</i> |
| 436 |
Copying output to backtrace.log. |
| 437 |
(gdb) <i>bt</i> |
| 438 |
#0 0x0000003000eb7472 in __select_nocancel () from /lib/libc.so.6 |
| 439 |
... |
| 440 |
(gdb) <i>set logging off</i> |
| 441 |
Done logging to backtrace.log. |
| 442 |
(gdb) <i>quit</i> |
| 443 |
</pre> |
| 444 |
|
| 445 |
<p> |
| 446 |
Ahora puede obtener la traza en el fichero <path>backtrace.log</path> y |
| 447 |
simplemente enviarla por correo electrónico o adjuntar el fichero al informe |
| 448 |
de error relacionado. |
| 449 |
</p> |
| 450 |
|
| 451 |
</body> |
| 452 |
</section> |
| 453 |
|
| 454 |
<section><!-- Core dumps --> |
| 455 |
|
| 456 |
<title>Volcados Core</title> |
| 457 |
|
| 458 |
<body> |
| 459 |
|
| 460 |
<p> |
| 461 |
En algunas ocasiones, los errores de ejecución son difíciles de reproducir, |
| 462 |
el programa tienes muchos hilos y es muy lento ejecutarlo en <c>gdb</c> o |
| 463 |
está embrollado cuando se realiza la ejecución con el depurador (no debería |
| 464 |
sorprender a nadie que al realizar las ejecuciones dentro del depurador se |
| 465 |
muestran más errores que al tratar de reproducirlos sin el depurador). En |
| 466 |
estos casos hay una herramienta que se muestra muy útil: el volcado core. |
| 467 |
</p> |
| 468 |
|
| 469 |
<p> |
| 470 |
Un volcado core es un fichero que contiene todo el área de memoria de un |
| 471 |
programa cuando éste ha fallado. Usando este fichero es posible extraer la |
| 472 |
traza de la pila, incluso si el programa ha fallado fuera de <c>gdb</c>, |
| 473 |
asumiendo que los volcados core están activados. Por defecto, los volcados |
| 474 |
core no están activados en Gentoo Linux (sin embargo, son activados por |
| 475 |
defecto en <uri link="http://www.gentoo.org/proj/en/gentoo-alt/bsd/fbsd/"> |
| 476 |
Gentoo/FreeBSD</uri>), por lo que tendrá que activarlos. |
| 477 |
</p> |
| 478 |
|
| 479 |
<p> |
| 480 |
Los ficheros de volcado core son generados directamente por el núcleo; por |
| 481 |
esta razón, el núcleo necesita tener esta característica activada en el |
| 482 |
momento de su construcción para que funcione correctamente. Normalmente las |
| 483 |
configuraciones por defecto del núcleo activan los ficheros de volcado |
| 484 |
core. Si está corriendo un núcleo incrustado, o ha configurado la sección |
| 485 |
standard kernel features (características estándar del núcleo), debería |
| 486 |
verificar las siguientes opciones: |
| 487 |
</p> |
| 488 |
|
| 489 |
<note> |
| 490 |
Puede saltarse este paso si no ha activado la opción “Configure standard |
| 491 |
kernel features en ningún momento, lo cual no debería hacerlo si no sabe si |
| 492 |
lo hizo o no. |
| 493 |
</note> |
| 494 |
|
| 495 |
<pre caption="Opciones del núcleo para activar los volcados core"> |
| 496 |
General Setup ---> |
| 497 |
Configure standard kernel features ---> |
| 498 |
Enable ELF core dumps |
| 499 |
</pre> |
| 500 |
|
| 501 |
<p> |
| 502 |
Los volcados core pueden ser activados al nivel de sistema o al nivel de |
| 503 |
sesión del intérprete de comandos. En el primer caso, todo en el sistema que |
| 504 |
produzca un error de ejecución y no tenga un manejador de ese error (mire |
| 505 |
más abajo algunas notas sobre el manejador de errores de KDE) será |
| 506 |
volcado. Cuando se activa al nivel de sesión, únicamente los programas que |
| 507 |
sean ejecutados en esa sesión generarán un volcado. |
| 508 |
</p> |
| 509 |
|
| 510 |
<p> |
| 511 |
Para activar los volcados core al nivel de sistema, tendrá que editar, bien |
| 512 |
<path>/etc/security/limits.conf</path> (si está usando PAM, situación por |
| 513 |
defecto), bien <path>/etc/limits.conf</path>. En el primer caso, debe |
| 514 |
definir un límite (hardware o más comúnmente software; para ficheros core, |
| 515 |
el cual puede ser cualquiera entre 0 y ningún límite). En el último caso, |
| 516 |
simplemente necesita definir la variable C al tamaño límite de un fichero |
| 517 |
core (aquí no existe "ilimitado"). |
| 518 |
</p> |
| 519 |
|
| 520 |
<pre caption="Ejemplo de regla para obtener ficheros core ilimitados cuando se usa PAM"> |
| 521 |
# /etc/security/limits.conf |
| 522 |
* soft core unlimited |
| 523 |
</pre> |
| 524 |
|
| 525 |
<pre caption="Ejemplo de regla para obtener ficheros core de hasta 20 MB cuando no se usa PAM"> |
| 526 |
# /etc/limits.conf |
| 527 |
* C20480 |
| 528 |
</pre> |
| 529 |
|
| 530 |
<p> |
| 531 |
Para activar fichero core en una sesión simple del intérprete de comandos |
| 532 |
puede usar el comando <c>ulimit</c> con la opción <c>-c</c>. 0 indica |
| 533 |
desactivado; cualquier otro número positivo es el tamaño en KB del fichero |
| 534 |
core generado, mientras que <e>unlimited</e> simplemente elimina el límite |
| 535 |
en las dimensiones de los ficheros core. A partir de ese momento, todos los |
| 536 |
programas que terminen como resultado de una señal como SIGABRT or SIGSEGV |
| 537 |
dejarán un fichero core que puede llamarse "core" o "core.<e>pid</e>" (donde |
| 538 |
pid es reemplazado por el identificador de proceso del programa que murió). |
| 539 |
</p> |
| 540 |
|
| 541 |
<pre caption="Ejemplo de uso de ulimit"> |
| 542 |
$ <i>ulimit -c unlimited</i> |
| 543 |
$ <i>crashing-program</i> |
| 544 |
[...] |
| 545 |
Abort (Core Dumped) |
| 546 |
$ |
| 547 |
</pre> |
| 548 |
|
| 549 |
<note> |
| 550 |
El comando <c>ulimit</c> es un comando interno en bash y zsh. En otros |
| 551 |
intérpretes de comandos puede tener otro nombre o incluso no estar |
| 552 |
disponible. |
| 553 |
</note> |
| 554 |
|
| 555 |
<p> |
| 556 |
Después de obtener un volcado core, puede ejecutar <c>gdb</c> sobre él, |
| 557 |
especificando tanto el fichero que generó el volcado core (tiene que ser |
| 558 |
exactamente el mismo binario, por lo que si recompila, el volcado core es |
| 559 |
inútil) y el camino al fichero core. Una vez que haya abierto <c>gdb</c> |
| 560 |
sobre él, puede seguir las mismas instrucciones detalladas arriba tal y como |
| 561 |
si se hubiera recibido la señal que mata el proceso en ese preciso instante. |
| 562 |
</p> |
| 563 |
|
| 564 |
<pre caption="Arrancado gdb con un fichero core"> |
| 565 |
$ <i>gdb $(el programa que murió) --core core</i> |
| 566 |
</pre> |
| 567 |
|
| 568 |
<p> |
| 569 |
Como alternativa, puede usar la capacidades de línea de comandos de |
| 570 |
<c>gdb</c> para obtener la traza sin entrar en modo interactivo. Esto |
| 571 |
también hace más fácil guardar la traza en un fichero o enviarla a una |
| 572 |
tubería (pipe) de cualquier tipo. El truco están en las opciones |
| 573 |
<c>--batch</c> y <c>-ex</c> que son aceptadas por <c>gdb</c>. Puede usar la |
| 574 |
siguiente función bash para obtener la traza completa de un volcado core |
| 575 |
(incluyendo todos los hilos de ejecución) en la salida estándar. |
| 576 |
</p> |
| 577 |
|
| 578 |
<pre caption="Función para obtener la traza completa de un volcado core"> |
| 579 |
gdb_get_backtrace() { |
| 580 |
local exe=$1 |
| 581 |
local core=$2 |
| 582 |
|
| 583 |
gdb ${exe} \ |
| 584 |
--core ${core} \ |
| 585 |
--batch \ |
| 586 |
--quiet \ |
| 587 |
-ex "thread apply all bt full" \ |
| 588 |
-ex "quit" |
| 589 |
} |
| 590 |
</pre> |
| 591 |
|
| 592 |
</body> |
| 593 |
|
| 594 |
</section> |
| 595 |
|
| 596 |
<section><!-- KDE crash handler's notes --> |
| 597 |
|
| 598 |
<title>Notas acerca del manejador de errores de ejecución de KDE</title> |
| 599 |
|
| 600 |
<body> |
| 601 |
|
| 602 |
<p> |
| 603 |
La aplicaciones basadas en KDE se ejecutan por defecto con su propio |
| 604 |
manejador de errores de ejecución, el cual es presentado al usuario como |
| 605 |
"Dr. Konqi" si está instalado (el paquete es <path>kde-base/kdebase</path> o |
| 606 |
<path>kde-base/drkonqi</path> (incluido en <path>kdebase-meta</path>). Este |
| 607 |
manejador de errores de ejecución muestra al usuario un diálogo informativo |
| 608 |
de que el programa ha fallado. En este diálogo hay una pestaña "Backtrace" |
| 609 |
(traza) que cuando es cargada llama a <c>gdb</c> y hace que éste cargue los |
| 610 |
datos y genere la traza completa en representación del usuario, mostrándola |
| 611 |
en la caja de texto principal y permitiendo que ésta sea salvada |
| 612 |
directamente a un fichero. Esa traza, normalmente, es suficientemente buena |
| 613 |
para informar de un problema. |
| 614 |
</p> |
| 615 |
|
| 616 |
<p> |
| 617 |
Cuando drkonqi no está instalado, los errores de ejecución no generarán un |
| 618 |
volcado core, y el usuario no recibirá ninguna información por defecto. Para |
| 619 |
evitar esto, es posible usar el argumento <c>--nocrashhandler</c> en todas |
| 620 |
las aplicaciones basadas en KDE. Esto desactivará el gestor de errores de |
| 621 |
ejecución completamente y dejará que las señales sean gestionadas por el |
| 622 |
sistema operativo como es normal. Esto es útil para generar ficheros core |
| 623 |
cuando drkonqi no está disponible o cuando se desea inspeccionar las trazas |
| 624 |
de la pila a mano. |
| 625 |
</p> |
| 626 |
|
| 627 |
</body> |
| 628 |
|
| 629 |
</section> |
| 630 |
|
| 631 |
<!-- TODO |
| 632 |
- add notes about GNOME's crash handler |
| 633 |
- add notes about renaming core dump files |
| 634 |
--> |
| 635 |
|
| 636 |
|
| 637 |
</chapter> |
| 638 |
|
| 639 |
</guide> |
| 640 |
|
| 641 |
<!-- kate: space-indent on; indent-width 2; replace-tabs on; indent-mode normal; --> |
Archives