Debugging cgi-scripts: Difference between revisions
From genomewiki
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
* [http://genome-source.cse.ucsc.edu/gitweb/?p=kent.git;a=blob;f=src/product/README.debug README.debug] in the source tree | * [http://genome-source.cse.ucsc.edu/gitweb/?p=kent.git;a=blob;f=src/product/README.debug README.debug] in the source tree | ||
* [https://lists.soe.ucsc.edu/pipermail/genome-mirror/2010-March/001677.html Debug the cgi-scripts with GDB] | * [https://lists.soe.ucsc.edu/pipermail/genome-mirror/2010-March/001677.html Debug the cgi-scripts with GDB] | ||
== Debugging with GDB == | |||
Complete instructions: | Complete instructions: | ||
| Line 13: | Line 16: | ||
Then: | Then: | ||
cd cgi-bin | cd cgi-bin | ||
gdb hgc | gdb --args hgc 'hgsid=4777921&c=chr21&o=27542938&t=27543085&g=pubsDevBlat&i=1000235064' | ||
To not forget the quotes, do not include the question mark. | To not forget the quotes, do not include the question mark from your internet browser. | ||
To get a stacktrace | To get a stacktrace of the place where it's aborting: | ||
break errAbort | break errAbort | ||
where | |||
== Finding memory problems with valgrind == | |||
Sometimes the program crashes at random places, because the stack or other datastructures have been destroyed by rogue code. You need valgrind to find the buggy code. | |||
Run the program like this: | |||
valgrind --tool=memcheck --leak-check=yes pslMap ~max/pslMapProblem.psl ~max/pslMap-dm3-refseq.psl out.temp | |||
== Profiling with gprof == | |||
When the program is too slow, you can ctrl-C and look for where it's stuck. Or run gprof, the show how much time each function takes. | |||
Revision as of 09:58, 2 January 2014
See also:
- README.debug in the source tree
- Debug the cgi-scripts with GDB
Debugging with GDB
Complete instructions:
make sure you have compiled with -ggdb by adding
export COPT=-ggdb
to your .bashrc (if using bash). You might need to make clean; make cgi afterwards. Also make sure that the CGIs use the right hg.conf. Run
export HGDB_CONF=<PATHTOCGIS>/hg.conf
Then:
cd cgi-bin gdb --args hgc 'hgsid=4777921&c=chr21&o=27542938&t=27543085&g=pubsDevBlat&i=1000235064'
To not forget the quotes, do not include the question mark from your internet browser.
To get a stacktrace of the place where it's aborting:
break errAbort where
Finding memory problems with valgrind
Sometimes the program crashes at random places, because the stack or other datastructures have been destroyed by rogue code. You need valgrind to find the buggy code.
Run the program like this:
valgrind --tool=memcheck --leak-check=yes pslMap ~max/pslMapProblem.psl ~max/pslMap-dm3-refseq.psl out.temp
Profiling with gprof
When the program is too slow, you can ctrl-C and look for where it's stuck. Or run gprof, the show how much time each function takes.
