TDE core libraries
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

185 lines
6.5KB

  1. Introduction
  2. ============
  3. This is a short tutorial on debugging KDE applications. Throughout this
  4. tutorial I will use "kedit" as example application.
  5. Configuring for debugging
  6. =========================
  7. You can use --enable-debug with the configure script, if you want to have
  8. debug code in your KDE libs. If you have the space and can stand code that's
  9. somewhat slower, this is worth it. The extra information really
  10. helps debugging and thus bugfixing.
  11. On the other hand, --disable-debug removes all debug messages, leading
  12. to a faster and cleaner desktop.
  13. Debugging with GDB
  14. ==================
  15. The recommended version of gdb to use is version 4.95 or higher, older
  16. versions have problems generating proper backtraces.
  17. There are three ways to debug an application with gdb:
  18. 1) You can start the application from within gdb.
  19. 2) You can attach gdb to an already running application.
  20. 3) You can run gdb after an application has crashed using a core file.
  21. Starting applications from within gdb
  22. =====================================
  23. To start an application with gdb you can start gdb as follows:
  24. > gdb kedit
  25. GNU gdb 4.95.0
  26. Copyright 2000 Free Software Foundation, Inc.
  27. GDB is free software, covered by the GNU General Public License, and you are
  28. welcome to change it and/or distribute copies of it under certain conditions.
  29. Type "show copying" to see the conditions.
  30. There is absolutely no warranty for GDB. Type "show warranty" for details.
  31. This GDB was configured as "i686-pc-linux-gnu"...
  32. (gdb)
  33. You can now set the command line arguments that you want to pass to kedit with
  34. the gdb command "set args":
  35. (gdb) set args myfile.txt
  36. (gdb)
  37. gdb has loaded the kedit executable on startup but it hasn't loaded any of
  38. the libraries yet. This means that you can set any breakpoints in the
  39. libraries yet. The easiest way to do that is to set a breakpoint in the
  40. first line of main and then start the program:
  41. (gdb) break main
  42. Breakpoint 1 at 0x804855c
  43. (gdb) run
  44. Starting program: /opt/kde/bin/kedit myfile.txt
  45. Breakpoint 1 at 0x4002cf18: file kedit.cpp, line 1595.
  46. Breakpoint 1, main (argc=2, argv=0xbffff814) at kedit.cpp:1595
  47. 1595 bool have_top_window = false;
  48. Current language: auto; currently c++
  49. (gdb)
  50. You can now set breakpoints everywhere. For example lets set a breakpoint
  51. in the KApplication constructor. Unfortunately gdb is not very good in
  52. handling C++ names, so it is not really possible to specify the constructor
  53. directly after the break command. Instead we look up a line of source
  54. code where we want to place the breakpoint. An external editor is of great
  55. use at this point. With the list command we can select the source file we
  56. are interested in and verify that we have found the correct source line:
  57. (gdb) list kapp.cpp:220
  58. 215 parseCommandLine( argc, argv );
  59. 216 }
  60. 217
  61. 218 KApplication::KApplication( bool allowStyles, bool GUIenabled ) :
  62. 219 QApplication( *KCmdLineArgs::qt_argc(), *KCmdLineArgs::qt_argv(),
  63. 220 GUIenabled ),
  64. 221 KInstance( KCmdLineArgs::about),
  65. 222 d (new KApplicationPrivate)
  66. 223 {
  67. 224 if (!GUIenabled)
  68. (gdb) break 224
  69. Breakpoint 2 at 0x4048aa7e: file kapp.cpp, line 224.
  70. (gdb)
  71. We can now continue the execution of kedit. Execution will stop when it hits
  72. a breakpoint of when the program exits. In this case execution will stop
  73. in the first line of the KApplication constructor:
  74. (gdb) continue
  75. Continuing.
  76. Qt: gdb: -nograb added to command-line options.
  77. Use the -dograb option to enforce grabbing.
  78. Breakpoint 2, KApplication::KApplication (this=0xbffff6a8, allowStyles=true,
  79. GUIenabled=true) at kapp.cpp:224
  80. 224 if (!GUIenabled)
  81. (gdb)
  82. Attaching gdb to already running applications
  83. =============================================
  84. Sometimes it is not practical to start an application from within gdb.
  85. E.g. in those cases where you didn't know the application was about to
  86. crash :-) When you get the friendly DrKonqi dialog informing you about
  87. a crash you are just in time to start your debugger.
  88. First lets attach gdb to an application that hasn't crashed (yet).
  89. You start with finding the process of the application with e.g. "ps -aux":
  90. > ps -aux | grep kedit
  91. bastian 21570 15.1 6.8 13740 8800 pts/6 S 15:34 0:01 kedit
  92. bastian 21582 0.0 0.3 1132 412 pts/6 R 15:34 0:00 grep kedit
  93. From this you learn that kedit has process id 21570. Now you can start gdb as
  94. follows:
  95. > gdb kedit 21570
  96. GNU gdb 4.95.0
  97. Copyright 2000 Free Software Foundation, Inc.
  98. GDB is free software, covered by the GNU General Public License, and you are
  99. welcome to change it and/or distribute copies of it under certain conditions.
  100. Type "show copying" to see the conditions.
  101. There is absolutely no warranty for GDB. Type "show warranty" for details.
  102. This GDB was configured as "i686-pc-linux-gnu"...
  103. /home1/bastian/21570: No such file or directory.
  104. Attaching to program: /opt/kde/bin/kedit, Pid 21570
  105. Reading symbols from /opt/kde/lib/kedit.so.0...done.
  106. Loaded symbols for /opt/kde/lib/kedit.so.0
  107. ....
  108. Reading symbols from /lib/ld-linux.so.2...done.
  109. Loaded symbols for /lib/ld-linux.so.2
  110. Reading symbols from /lib/libnss_compat.so.2...done.
  111. Loaded symbols for /lib/libnss_compat.so.2
  112. Reading symbols from /lib/libnsl.so.1...done.
  113. Loaded symbols for /lib/libnsl.so.1
  114. 0x40c3d88e in __select () from /lib/libc.so.6
  115. (gdb)
  116. You will usually end up in the middle of a select() call from the event-loop.
  117. This is the place where a KDE application spends most of its time, waiting
  118. for things to happen.
  119. A backtrace will typically look something like this:
  120. (gdb) bt
  121. #0 0x40c3d88e in __select () from /lib/libc.so.6
  122. #1 0x40a22844 in __DTOR_END__ () at fam.c++:356
  123. #2 0x407293bf in QApplication::enter_loop (this=0xbffff6e8)
  124. at kernel/qapplication.cpp:2552
  125. #3 0x406b1d7b in QApplication::exec (this=0xbffff6e8)
  126. at kernel/qapplication_x11.cpp:2217
  127. #4 0x4002d500 in main (argc=1, argv=0xbffff854) at kedit.cpp:1662
  128. #5 0x40bbba5e in __libc_start_main (main=0x8048568 <main>, argc=1,
  129. argv=0xbffff854, init=0x8048514 <_init>, fini=0x80486cc <_fini>,
  130. rtld_fini=0x4000aa20 <_dl_fini>, stack_end=0xbffff84c)
  131. at ../sysdeps/generic/libc-start.c:92
  132. (gdb)
  133. Getting core dumps
  134. ==================
  135. If you want to have a core dump after your application crashes you need to
  136. do two things:
  137. 1) Disable the KDE crash handler. This can be done either by using the
  138. --nocrashhandler command line option or by setting the KDE_DEBUG environment
  139. variable to some value e.g. KDE_DEBUG=true.
  140. 2) Enable core dump generation by changing the so called 'ulimits' with the
  141. following command:
  142. ulimit -c unlimited