| Bug Report
|
|---|
| Reproduzco un correo que mando Andrej a la lista de correo que menciona la
importancia y requisitos para reportar fallas.
| I reproduce an e-mail than Andrej sent to the mailing list that
recall the importance of reporting bugs and the correct way of reporting them.
|
From: "Andrej Falout"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Tuesday, September 14, 2004 6:07 AM
Subject: RE: [Aubit4gl-discuss] Another SegFault
Hola,
Escribo esto a todos lo que reportan BUGS. Todos estamos agradecidos por los reportes
de los BUGS - no podemos arreglar lo que no sabemos que esta mal.
Reportar los BUG y arreglarlos son parte crucial del proceso de desarrollo, y es la
mejor manera de asegurar una funcionalidad estable y robusta.
Y aqui es la parte donde vienen los 'peros' :-)
Pero, es extremadamente dificil reparar problemas que no [pdemos REPRODUCIR.
Especialmente cuando hay volcados de memoria (core dumps). Las mas veces sera imposible.
Por lo tanto, por favor siempre proporciona los medio para REPRODUCIR el error.
Esto significa que debes de proporcionar codigo compilable AUTO CONTENIDO e
independiente que contenga TODO lo que se necesita para EJECUTARSE y
obtener el mismo resultado (falla( que tu. Al conjunto de todos los componentes necesarios,
incluyendo la descripcion del problema, es comunmente llamada un "caso de prueba".
No es suficiente que envien la pieza del codigo donde ocurre el error, sin todas las
otras piezas del codigo, archivos de formas, tablas de la base de datos y en algunos
casos los datos mismos, que son necesarios para ejecutar el caso de prueba.
Tampoco es correcto que envien el programa completo con algunas miles de lineas de
codigo, que nosotros no podemos compilar y menos ejecutar.
Debe de ser razonablemente pequeño, debe de ser autocontenido, debe de copilar y debe
de ejecutarse con el comportamiento descrito bajo la condiciones descritas, todo en
computadora del desarrollador que arreglara el problema.
Lo anterior aplica especialmente con los 'vuelcos de memoria' (core dumps). Sin un
caso de prueba, y sin un rastreo de memoria (core dump back trace), y aun sin un
rastreo con Valgrind, sera dificil esperar que se arregle.
Ademas de todo eso, queremos no solo arreglar el problema, queremos asegurarnos de que
nunca reaparezca, en el proceso constante y sin fin de mejorar el compilador Aubit.
Para que esto suceda, necesitamos que el CASO DE PRUEBA forme parte de nuestras
pruebas de regresion. Para que se pueda convertir en un caso de regresion, tiene que
existir primero.
Por favor ayudenos a ayudarlo,
Saludos,
Andrej
|
From: "Andrej Falout"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Tuesday, September 14, 2004 6:07 AM
Subject: RE: [Aubit4gl-discuss] Another SegFault
Hi guys,
I'm writing this to everyone reporting bugs. We are all grateful for bug
reports - we can't fix what we do not know is wrong. Bug reports and bug
resolution are crucial part of development process, and beast way to ensure
stabile and robust functionality.
And here is the part where word 'but' comes :-)
But, it is extremely hard to fix problems one can not REPRODUCE.
Especially when talking about core dumps. More often then not, it can be
impossible.
Therefore, please always provide means to REPRODUCE the error. This means
that you need to supply SELF CONTAINED and stand-alone compilable code that
contains ALL that is needed to RUN it and get the same result (bug) you see.
This collection of all needed components, including the description of the
problem, is usually referred to as "test case".
It is not enough to send a peace of code where error happens, without all
other peaces of code, form files, database tables and in some case data
itself, which is needed to run the test case.
It is also no good to send complete program of few thousands lines of code,
that we cannot make to compile, not to mention execute.
It must be reasonably small, must be self contained, must compile, and must
run and exhibit described behavior under described conditions, all on the
computer of the developer that is to fix the problem.
All the above especially applies in case of core dumps. Without a test case,
and without a core dump back trace, and without even a Valgrind trace, it
will be hard to expect to get a fix.
On top of that, we all wont not only to fix the problem, but to make sure it
never appears again later, in the process of Constant And Never Ending
Improvement of Aubit Compiler ("Caneiac" :-). For this to happen, we need a
TEST CASE to become a part of our regression tests. For it to become a
regression test, it needs to exist first.
Please help us to help you,
Cheers,
Andrej
|
| Tambien reproduzco las instrucciones de Mike para poder analizar un volcado
de memoria.
| Also, here is the instruction from Mike to analyze a core dump or
segmentation violation.
|
From: "Mike Aubury"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Tuesday, September 14, 2004 11:50 AM
Subject: Re: [Aubit4gl-discuss] Another SegFault
Hay que compilar el programan activando la opcion de depuracion - busca la lista de
correos por la opcion '-debug'..
Ejecuta el programa dentro del depurador GNU (gdb)
$ gdb myprog.4ae
gdb> run
...time passes
Seg Fault
gdb>bt
Envia el rastreo..
Tambien puedes querer instalar valgrind y jugar con el tambien - tambein busca en la
lista ....
|
From: "Mike Aubury"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Tuesday, September 14, 2004 11:50 AM
Subject: Re: [Aubit4gl-discuss] Another SegFault
Compile the program with debugging on - search the mailing list for '-debug'..
Then run the program under the GNU debugger (gdb)
$ gdb myprog.4ae
gdb> run
...time passes
Seg Fault
gdb> bt
And send that backtrace..
You may also want to install valgrind and play with that too - again search
the list...
|
| Yo he usado poco el gdb pero encontre que para poder ejecutar un programa
con parametros hay que ejecutar el comando gdb sin los parametros y despues
asignar los parametros con el comando set args:
| With my few experince with gdb I found a method to execute a 'gdb'
of a program with parameters, execute gdb without the parameters and then assign
them with the command set args:
|
| Por ejemplo para hacer un analisis de una falla al compilar un programa, se
darian estos comandos, asumo que en la linea del error se hace referencia a la
variable fprop por lo cual desplegamos su valor para analizar la falla:
| Supose you need to analyze a segmentation fault during compilation of a
program, you need to type the following assuming that the backtrace reported an error
in tha varable fprop:
|
gdb /opt/aubit4gl/bin/4glc
...
(gdb)set args prog.4gl -o prog.4ae
(gdb)run
...
(gdb)bt
...
(gdb)print fprop
...
(gdb)print *fprop
...
|
| Tambien reproduzco el correo donde Mike da unos tips para ejecutar
Valgrind .
| Here's also the mail from Mike about a tiips to execute
Valgrind .
|
From: "Mike Aubury"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Thursday, August 12, 2004 9:12 AM
Subject: Re: [Aubit4gl-discuss] problems with port to pg
No se la manera oficial de hacerlo - Yo solo uso:
--logfile=algunarchivo or --gdb-attach=yes
en el primer caso tendras un archivo llamado algunarchivo.pid
en el segundo caso, algunas veces tienes que ejecutar "stty sane" para
dejar la pantalla funcionando nuevamente.
--- John O'Gorman wrote:
valgrind es nuevo para mi. Encontre que esta en mi maquina con SuSE 9.1 pero
no existe la pagina de "man" o "info" para el.
Cuando lo ejecuto con un programa 4GL, obtengo una pantalla revuelta.
Tanto valgrind y el 4GL hacen garabatos sobre la ventana "curses".
Tienen una guia para principiantes que recomendar?
Basicamente, como se hace la depuracion en una terminal y el desplegado en otra?
John O'G
|
From: "Mike Aubury"
To: <aubit4gl-discuss@lists.sourceforge.net>
Sent: Thursday, August 12, 2004 9:12 AM
Subject: Re: [Aubit4gl-discuss] problems with port to pg
I don't know the official way - I tend to just use
--logfile=somefilename or --gdb-attach=yes
for the former you'll end up with files
somefilename.pid
For the latter - you sometimes need to "stty sane" to
get the screen working again..
--- John O'Gorman wrote:
valgrind is new to me. I found that it is on my SuSE 9.1 machine but no
man of info pages for it.
When I just ran it with a 4GL program, I got a scrambled screen.
Both valgrind and 4GL were scribbling over the curses window.
Do you have an idiot's guide to recommend?
In general, how do debug on one terminal and get the
display on another?
John O'G
|
| Yo use los siguientes comandos para ejecutar el valgrind:
| I use this command to execute valgrind:
|
valgrind --tool=addrcheck --logfile=<logfile> <prog>.4ae
o
valgrind --tool=memcheck --logfile=<logfile> <prog>.4ae
seguido de
more <logfile>.pid<num>
|