Difference between revisions of "Development/Tutorials/Debugging/Debugging IOSlaves"

Jump to: navigation, search
m (Development/FAQs/Debugging FAQ/Debugging ioslaves moved to Development/Tutorials/Debugging/Debugging IOSlaves: this belongs with the tutorials, not the FAQ's. in fact, i don't even see it linked in the FAQ's)
m (Attaching gdb to an io-slave: grammer correction)
 
(16 intermediate revisions by 12 users not shown)
Line 3: Line 3:
 
==How does an io-slave get started?==
 
==How does an io-slave get started?==
  
Your application request 'klauncher' via DCOP for a slave. If 'klauncher' does  
+
Your application requests 'klauncher' via DBus for a slave. If 'klauncher' does not have an idle slave ready, it will ask kdeinit to start a new one. kdeinit forks and dlopens the library that contains the io-slave.
not have an idle slave ready, it will ask kdeinit to start a new one.
+
Then it calls a function called kdemain() in the library.
kdeinit forks and dlopens the library that contains the io-slave.
+
Then it calls kdemain() or, if that is not present, main() in the library.
+
  
==Attaching gdb to a io-slave==
+
==Attaching gdb to an io-slave==
 
Due to the above sequence it is rather hard to get an io-slave in your
 
Due to the above sequence it is rather hard to get an io-slave in your
 
debugger. But wait there is hope. You can start <tt>klauncher</tt> in such a way
 
debugger. But wait there is hope. You can start <tt>klauncher</tt> in such a way
Line 14: Line 12:
  
 
E.g. to start all 'http' slaves in debug mode, you type:
 
E.g. to start all 'http' slaves in debug mode, you type:
 
+
<pre>
        in KDE 3: KDE_SLAVE_DEBUG_WAIT=http kdeinit
+
KDE_SLAVE_DEBUG_WAIT=http kdeinit4
        in KDE 4: KDE_SLAVE_DEBUG_WAIT=http kdeinit4
+
</pre>
  
 
This will restart 'kdeinit' and 'klauncher'.
 
This will restart 'kdeinit' and 'klauncher'.
 +
 +
Note:
 +
The string after the equal signal designates the name of a service, not the name of the slave! E.g. if you want to debug the kio_imap4, you must use:
 +
<pre>
 +
KDE_SLAVE_DEBUG_WAIT=imap kdeinit4
 +
</pre>
 +
 +
For example, these commands don't work:
 +
<pre>
 +
KDE_SLAVE_DEBUG_WAIT=imap4 kdeinit4
 +
KDE_SLAVE_DEBUG_WAIT=143 kdeinit4
 +
</pre>
  
 
When your application now requests a http slave, the slave will be started
 
When your application now requests a http slave, the slave will be started
Line 26: Line 36:
 
In the terminal from which you started kdeinit you will get the following
 
In the terminal from which you started kdeinit you will get the following
 
message:
 
message:
 
+
<pre>
 
kdeinit: Suspending process
 
kdeinit: Suspending process
 
kdeinit: 'gdb kdeinit 16779' to debug
 
kdeinit: 'gdb kdeinit 16779' to debug
 
kdeinit: 'kill -SIGCONT 16779' to continue
 
kdeinit: 'kill -SIGCONT 16779' to continue
 +
</pre>
  
 
You can now debug your slave by typing (or pasting) 'gdb kdeinit 16779' in
 
You can now debug your slave by typing (or pasting) 'gdb kdeinit 16779' in
Line 47: Line 58:
 
KLauncher can be told to run certain io-slaves through valgrind. The following
 
KLauncher can be told to run certain io-slaves through valgrind. The following
 
command can be used to let klauncher run all https io-slaves via valgrind:
 
command can be used to let klauncher run all https io-slaves via valgrind:
 
+
<pre>
        KDE_SLAVE_VALGRIND=https kdeinit
+
KDE_SLAVE_VALGRIND=https kdeinit4
 +
</pre>
  
 
The valgrind output will appear as the stderr output of the kdeinit process.
 
The valgrind output will appear as the stderr output of the kdeinit process.
 
The $VALGRIND_OPTS environment variable can be used to pass options to valgrind.
 
The $VALGRIND_OPTS environment variable can be used to pass options to valgrind.
 
If you want to use a different skin:
 
If you want to use a different skin:
 +
<pre>
 +
KDE_SLAVE_VALGRIND_SKIN=callgrind      ( for example )
 +
</pre>
 +
==How to get debug output==
  
        KDE_SLAVE_VALGRIND_SKIN=calltree      ( for example )
+
=== GUI ===
  
 +
# Press ALT+F2.
 +
# Enter 'kdebugdialog --fullmode' without the quotes and press enter.
 +
# Select the desired number in the "Debug area", e.g. 7103 for http.
 +
# In the [Information] box, select "File" as the output.
 +
# Enter the desired file name, e.g. /tmp/kio_http.log.
 +
# Press OK to close the dialog.
 +
# Press ALT+F2, type ''kdeinit4'' and press enter or alternatively log out of KDE and log back in.
  
==How to get debug output==
+
===Manual===
 
It is useful to redirect the debug output of your particular slave to a file  
 
It is useful to redirect the debug output of your particular slave to a file  
 
instead of stderr. E.g. I myself use the following lines in
 
instead of stderr. E.g. I myself use the following lines in
 
$KDEDIR/share/config/kdebugrc.
 
$KDEDIR/share/config/kdebugrc.
 
+
<pre>
      [7113]
+
[7113]
      InfoOutput=0
+
InfoOutput=0
      InfoFilename=/tmp/http
+
InfoFilename=/tmp/http
      [7103]
+
[7103]
      InfoOutput=0
+
InfoOutput=0
      InfoFilename=/tmp/http  
+
InfoFilename=/tmp/http  
 
+
</pre>
 
This redirects all debug info for areas 7103 and 7113 (as used by kio_http)  
 
This redirects all debug info for areas 7103 and 7113 (as used by kio_http)  
 
to the file /tmp/http.
 
to the file /tmp/http.
Line 74: Line 97:
 
To get debug information from the SMB slave you can add the following to
 
To get debug information from the SMB slave you can add the following to
 
kioslaverc:
 
kioslaverc:
 
+
<pre>
 
[SMB]
 
[SMB]
 
DebugLevel=100
 
DebugLevel=100
 
+
</pre>
 
This will print additional debug info to the stderr of your kdeinit process,
 
This will print additional debug info to the stderr of your kdeinit process,
 
which typically ends up in ~/.X.err or ~/.xsession-errors
 
which typically ends up in ~/.X.err or ~/.xsession-errors
 +
 +
== specific kioslaves ==
 +
* [[Development/Tutorials/Debugging/Debugging IOSlaves/Debugging kio_fish|kio_fish]]
 +
* [[Development/Tutorials/Debugging/Debugging IOSlaves/Debugging kio_sftp|kio_sftp]]

Latest revision as of 17:39, 25 June 2012

This page describes how you can debug an ioslave with gdb.

Contents

[edit] How does an io-slave get started?

Your application requests 'klauncher' via DBus for a slave. If 'klauncher' does not have an idle slave ready, it will ask kdeinit to start a new one. kdeinit forks and dlopens the library that contains the io-slave. Then it calls a function called kdemain() in the library.

[edit] Attaching gdb to an io-slave

Due to the above sequence it is rather hard to get an io-slave in your debugger. But wait there is hope. You can start klauncher in such a way that slaves for a certain protocol (the first parameter of KIO::SlaveBase() constructor of the slave class) are started in debug mode.

E.g. to start all 'http' slaves in debug mode, you type:

KDE_SLAVE_DEBUG_WAIT=http kdeinit4

This will restart 'kdeinit' and 'klauncher'.

Note: The string after the equal signal designates the name of a service, not the name of the slave! E.g. if you want to debug the kio_imap4, you must use:

KDE_SLAVE_DEBUG_WAIT=imap kdeinit4

For example, these commands don't work:

KDE_SLAVE_DEBUG_WAIT=imap4 kdeinit4
KDE_SLAVE_DEBUG_WAIT=143 kdeinit4

When your application now requests a http slave, the slave will be started by kdeinit, but before it calls kdemain() (cq. main()) it will suspend the slave by sending it a SIGSTOP signal.

In the terminal from which you started kdeinit you will get the following message:

kdeinit: Suspending process
kdeinit: 'gdb kdeinit 16779' to debug
kdeinit: 'kill -SIGCONT 16779' to continue

You can now debug your slave by typing (or pasting) 'gdb kdeinit 16779' in a terminal. If you don't want to debug a slave you can let it continue by sending it a SIGCONT by typing 'kill -SIGCONT 16779'.

Be aware that slaves will not be killed while they are suspended.

Once you have started gdb, you can set e.g. breakpoints and then resume the slave by typing 'continue'. The debugger will return immediate with a message that a SIGSTOP has been received so you will have to type 'continue' a second time.

See also Windows-specific notes on debugging io-slaves.

[edit] Debugging io-slaves with valgrind

KLauncher can be told to run certain io-slaves through valgrind. The following command can be used to let klauncher run all https io-slaves via valgrind:

KDE_SLAVE_VALGRIND=https kdeinit4

The valgrind output will appear as the stderr output of the kdeinit process. The $VALGRIND_OPTS environment variable can be used to pass options to valgrind. If you want to use a different skin:

KDE_SLAVE_VALGRIND_SKIN=callgrind      ( for example )

[edit] How to get debug output

[edit] GUI

  1. Press ALT+F2.
  2. Enter 'kdebugdialog --fullmode' without the quotes and press enter.
  3. Select the desired number in the "Debug area", e.g. 7103 for http.
  4. In the [Information] box, select "File" as the output.
  5. Enter the desired file name, e.g. /tmp/kio_http.log.
  6. Press OK to close the dialog.
  7. Press ALT+F2, type kdeinit4 and press enter or alternatively log out of KDE and log back in.

[edit] Manual

It is useful to redirect the debug output of your particular slave to a file instead of stderr. E.g. I myself use the following lines in $KDEDIR/share/config/kdebugrc.

[7113]
InfoOutput=0
InfoFilename=/tmp/http
[7103]
InfoOutput=0
InfoFilename=/tmp/http 

This redirects all debug info for areas 7103 and 7113 (as used by kio_http) to the file /tmp/http.

To get debug information from the SMB slave you can add the following to kioslaverc:

[SMB]
DebugLevel=100

This will print additional debug info to the stderr of your kdeinit process, which typically ends up in ~/.X.err or ~/.xsession-errors

[edit] specific kioslaves


This page was last modified on 25 June 2012, at 17:39. This page has been accessed 9,160 times. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2.
KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal