HTCondorWiki: Execution Profiling

 
 This method is useful when you are called in to diagnose a condor daemon that is using lots of cpu (or blocking a lot on I/O) for an unknown reason. Although crude, I have found this method to lead to the source of trouble in numerous cases.
 
-If pstack or gstack are available, just use those.  If not, you can use gdb.
+If =pstack= or =gstack= are available, just use those.  If not, you can use =gdb=.
 
-Here&#8217;s an example gdb script for the schedd:
+Here's an example gdb script for the schedd:
 
 {verbatim}
 add-symbol-file /path/to/condor_schedd.dbg
@@ -21,7 +21,9 @@
 
 If the stack shows that the schedd is usually in a certain part of the code, this may lead you to the source of trouble.
 
-If you need to get the condor admin to do this for you, then it is nice to make it even simpler. Below is a simple script to do the sampling. (Note that it doesn&#8217;t load the .dbg file, just to keep things simple.)
+Beware that gdb (and gstack) may sometimes leave the process in a trapped state.  Send SIGCONT to the process to let it resume.
+
+If you need to get the condor admin to sample the stack for you, then it is nice to make it even simpler. Below is an example script to do the sampling. (Note that it doesn't load the .dbg file, just to keep things simple.)
 
 {verbatim}
 #!/bin/sh
@@ -44,7 +46,8 @@
    where
    quit
 EOF
-
+# in case gdb leaves the process trapped
+kill -CONT $PID
 sleep 5
 done
 {endverbatim}
@@ -53,7 +56,7 @@
 
 Callgrind is a wonderful profiling tool. The one big disadvantage of it is that it slows down the application considerably (~20 times in my experience).
 
-Here&#8217;s an example of how to run callgrind on the collector.
+Here's an example of how to run callgrind on the collector.
 
 {verbatim}
 condor_off -collector
@@ -63,7 +66,7 @@
 PID=$!
 {endverbatim}
 
-You will see some files in the current working directory named &#8220;callgrind.out.$PID&#8221; and &#8220;callgrind.info.$PID&#8221;. Change the ownership of these from root to the condor user or callgrind will have trouble writing to them when the program exits.
+You will see some files in the current working directory named =callgrind.out.$PID= and =callgrind.info.$PID=. Change the ownership of these from root to the condor user or callgrind will have trouble writing to them when the program exits.
 
 {verbatim}
 chown condor:condor callgrind.*.$PID