diff --git a/docs/bugs.html.in b/docs/bugs.html.in
index 201705b452..560dfa4409 100644
--- a/docs/bugs.html.in
+++ b/docs/bugs.html.in
@@ -77,6 +77,35 @@
       <li>For QEMU/KVM, the domain logfile from /var/log/libvirt/qemu</li>
     </ul>
 
+    <p>
+      If the bug leads to a tool linked to libvirt crash, then the best
+      is to provide a backtrace along with the scenario used to get the
+      crash, the simplest is to run the program under gdb, reproduce the
+      steps leading to the crash and then issue a gdb "bt" command to
+      get the stack trace, attach it to the bug. Note that for the
+      data to be really useful libvirt debug informations must be present
+      for example by installing libvirt debuginfo package on Fedora or
+      Red Hat Enterprise Linux (with debuginfo-install libvirt) prior
+      to running gdb.</p>
+    <p>
+      It may also happen that the libvirt daemon itself crashes or get stuck,
+      in the first case run it (as root) under gdb, and reproduce the sequence
+      leading to the crash, similary to a normal program provide the
+      "bt" backtrace information to where gdb will have stopped.<br/>
+      But if libvirtd get stuck, for example seems to stop processing
+      commands, try to attach to the faulty daemon and issue a gdb command
+      "thread apply all bt" to show all the threads backtraces, as in:</p>
+      <pre> #  ps -o etime,pid `pgrep libvirt`
+... note the process id from the output
+# gdb /usr/sbin/libvirtd
+.... some informations about gdb and loading debug data
+(gdb) attach $the_damon_process_id
+....
+(gdb) thread apply all bt
+.... informations to attach to the bug
+(gdb)
+</pre>
+
     <p>
       If requesting a new feature attach any available patch to the ticket
       and also email the patch to the libvirt mailing list for discussion