WWW-www.enlightenment.org pushed a commit to branch master. http://git.enlightenment.org/website/www-content.git/commit/?id=6991e959355b384de9eb98e75a107900de144118
commit 6991e959355b384de9eb98e75a107900de144118 Author: Gareth Halfacree <[email protected]> Date: Thu Dec 7 06:34:52 2017 -0800 Wiki page gdb.md changed with summary [] by Gareth Halfacree --- pages/develop/debug/c/gdb.md.txt | 31 ++++++++++++++----------------- 1 file changed, 14 insertions(+), 17 deletions(-) diff --git a/pages/develop/debug/c/gdb.md.txt b/pages/develop/debug/c/gdb.md.txt index 1d2dbcb63..0bd6f0e68 100644 --- a/pages/develop/debug/c/gdb.md.txt +++ b/pages/develop/debug/c/gdb.md.txt @@ -1,5 +1,3 @@ -## Wrong function on an object ## - --- ~~Title: Debugging with GDB~~ --- @@ -12,7 +10,7 @@ The GNU Debugger (GDB) is an invaluable tool for tracking down the precise cause ## Debugging an Incorrect Object ## -The code below creates three Elementary objects: ``win``, ``box`` and an anonymous button. It displays a window with an "Quit" button which closes the window when it is clicked. Enter the following and save it as "hello.c": +The code below creates three Elementary objects: ``win``, ``box`` and an anonymous button. It displays a window with a "Quit" button, which closes the window when it is clicked. Enter the following and save it as "hello.c": ```c #define EFL_EO_API_SUPPORT 1 @@ -74,13 +72,13 @@ Then execute the program: ERR<12993>:eo lib/eo/eo.c:605 _efl_object_call_resolve() in ../src/lib/efl/interfaces/efl_pack.eo.c:6: func 'efl_pack' (1656) could not be resolved for class 'Efl.Ui.Win'. ``` -The cause of this error is that the ``efl_pack()`` function is called on the incorrect object, ``win``. The error log says that the ``efl_pack`` is not in the ``Efl.Ui.Win`` API, and so that the error is coming from the application and not from EFL itself. +This error is caused by the ``efl_pack()`` function being called on an incorrect object, ``win``. The error log explains that the ``efl_pack`` is not in the ``Efl.Ui.Win`` API, and so that the error is coming from the application and not from EFL itself. For a more complicated application, this basic trace is not enough to track down the precise location of the error. Fortunately, EFL provides a macro for backtraces: ``EINA_LOG_ABORT``. -A message generated by CRI macro can automatically call ``abort()`` once a message of a given log level is printed. This is controlled by the environment variable ``EINA_LOG_ABORT`` and the level to be considered critical with ``EINA_LOG_ABORT_LEVEL``. This means the program will stop at the first error which meets these two requirements. +A message generated by the ``EINA_LOG_CRI()`` macro can automatically call ``abort()`` once a message of a given log level is printed. This is controlled by the environment variable ``EINA_LOG_ABORT``, and the level to be considered critical by the environment variable ``EINA_LOG_ABORT_LEVEL``. When enabled the program will stop at the first error which meets both of the two requirements. -Run GDB over your application to receive the following backtrace: +Run GDB over the application with ``EINA_LOG_ABORT_LEVEL=4`` and ``EINA_LOG_ABORT=1`` set to receive the following backtrace: ```gdb EINA_LOG_ABORT_LEVEL=4 EINA_LOG_ABORT=1 gdb hello @@ -98,7 +96,7 @@ ERR<13088>:eo lib/eo/eo.c:605 _efl_object_call_resolve() in ../src/lib/efl/inter Thread 1 "debugging" received signal SIGABRT, Aborted. 0x00007ffff3e998a0 in raise () from /usr/lib/libc.so.6 -(gdb) bt +(gdb) backgrace #0 0x00007ffff3e998a0 in raise () from /usr/lib/libc.so.6 #1 0x00007ffff3e9af09 in abort () from /usr/lib/libc.so.6 #2 0x00007ffff739ee25 in eina_log_print_unlocked (domain=<optimized out>, level=EINA_LOG_LEVEL_ERR, @@ -136,16 +134,15 @@ Thread 1 "debugging" received signal SIGABRT, Aborted. The ``efl_pack()`` function is in frame five, so is called from frame six. -Go to frame seven: +Go to frame six: ```gdb -(gdb) fr 6 +(gdb) frame 6 #6 0x00005555555553d1 in efl_main (data=<optimized out>, ev=<optimized out>) at gdb.c:37 37 efl_add(EFL_UI_BUTTON_CLASS, box, // win instead of box ``` -This frame shows that the button constructor (line 37) contains the cause of the issue, and we can see the error at line 40 of "hello.c". - +This frame shows that the button constructor which begins on line 37 (``at gdb.c:37``) is responsible for the problem. Looking at the source code for the application, walk down from line 37 until you find the line in which ``win`` is used instead of ``box`` - which is line 40. This is the line which contains the error, and which must be corrected for the program to function correctly. ## Debugging a Callback Function ## @@ -201,7 +198,7 @@ efl_main(void *data EINA_UNUSED, const Efl_Event *ev EINA_UNUSED) EFL_MAIN() ``` -Save the program as "helloworld.c", compile it, and run it. The program will quit with a segmentation fault (segfault) error when the "Crash" button is clicked; in other words, during the callback function. +Save the program as "helloworld.c", compile it with the ``-g`` flag to include debugging symbols, and run it. The program will quit with a segmentation fault (segfault) error when the "Crash" button is clicked; in other words, during the callback function. To debug this, load the program into GDB and run it: @@ -212,7 +209,7 @@ gdb helloworld Thread 1 "debugging2" received signal SIGSEGV, Segmentation fault. _quit (data=0x400000025528, event=0x7fffffffdfe0) at gdb2.c:15 15 printf("Pi = %d\n", *pi); // segfault accessing 0x0 address -(gdb) bt +(gdb) backtrace #0 _quit (data=0x400000025528, event=0x7fffffffdfe0) at helloworld.c:15 #1 0x00007ffff5cdd967 in _event_callback_call (legacy_compare=1 '\001', event_info=<optimized out>, desc=<optimized out>, pd=0x555555b520c0, obj_id=<optimized out>) at lib/eo/eo_base_class.c:1542 @@ -257,13 +254,13 @@ To look at the problem more deeply: * Print what it points to ```bash -(gdb) fr 0 +(gdb) frame 0 #0 _quit (data=0x400000025528, event=0x7fffffffdfe0) at gdb2.c:15 15 printf("Pi = %d\n", *pi); // segfault accessing 0x0 address -(gdb) p pi +(gdb) print pi $1 (int *) 0x0 -(gdb) p *pi +(gdb) print *pi Cannot access memory at address 0x0 ``` -This demonstrates the problem: address ``0x0`` cannot be accessed. Using these techniques, even if the callback functions are called from Efl.Event and so generate lots of traces, it is quite simple to track down these types of bug. \ No newline at end of file +This demonstrates the problem: address ``0x0`` cannot be accessed. Using these techniques, even if the callback functions are called from ``Efl.Event`` and so generate lots of traces, it is quite simple to track down these types of bug. \ No newline at end of file --
