Sunday, 4. February 2007, 12:44:18
Java, Debug, Programming
如果没有接触过命令式的调试器,看一下这个
JDB Debugging Tutorial,举了一个例子,把调试相关的东西都介绍了一些,不过不是太详细,但是比较容易理解。然后还有个
Part 2,又介绍了几个命令。读完以后应该就基本上会用jdb了,也对这个命令式的调试器有所了解了。
这一篇
'jdb' - The Java Debugger介绍地更深入一些,包括如何调试已经在运行的程序和调试多线程的程序。不过对于jdb的命令只是稍有解释,没有举例子说明。对于使用过gdb的朋友,可能理解起来会比较方便。我也只是把比较常用命令的作用在这里介绍一下吧:
run 在jvm中以调试模式运行所调试的程序
cont 继续运行程序(在程序暂停时)
next 运行当前行的程序
step 运行当前行程序,如果是方法则进入
step up 运行到当前方法结束
print <表达式> 输出表达式的值
set <左值>=<表达式> 将左值的值设定为表达式的值
locals 输出所有局部变量的值
stop at <行数> 在某行设置断点
stop in <方法> 命令在方法开始处设置断点
clear <行数|方法> 清除所指定的断点
clear 列出所有断点
monitor <命令> 当程序暂停时自动执行命令
monitor 列出所有的monitor
watch <变量> 运行到变量的值改变时停止
unwatch<变量> 取消watch
list [行数|方法] 列出(从[行数|方法]开始的)源代码
classes 列出所有已知的类
<n> <命令> 执行命令n次
exit 或 quit 退出jdb
我想再说几点,一个是直接调用jdb Classname的话调试时没法列出源程序代码,至少在我这里是这样,要用
jdb -classpath . Classname
才行;再一个就是jdb好像不像gdb那样,命令有缩写的形式,比如run可以用r,next可以用n,这不太方便,也可能有只是我没发现而已,呵呵。
Monday, 7. August 2006, 14:28:23
Linux, Programming, Debug, ncurses
ncurses算是一个管理字符界面屏幕输出的库,所以使用ncurses库写的程序通常要清空整个屏幕,而且输出不是一段一段的,而是有格式有布局的,这在用gdb调试时按照默认的形式是很别扭的,会使输出很混乱,所以我们在调试ncurses的程序时,要对gdb进行一些设置,以便我们找到错误的所在。
一个方便的办法是把我们要调试的程序的输出都重定向到另一个终端上,这样就会把gdb的命令提示和我们的输出分开了,具体的方法是这样的:
我们打开两个终端(一个用来使用gdb,另一个用来显示所调试程序的输出),这两个终端是什么是无所谓的(可以是xterm,rxvt,konsole,或者virtual consoles),但是应该不能是一个多页面终端的两个tab,因为我在konsole实验的时个那样会提示找不到/dev/pts/x文件。
然后我们先切换到第一个终端,运行gdb filename,filename就是要调试的文件的名称(这个应该不会不知道吧...),进入gdb。接着切换到第二个终端,看看它的设备名称
$ tty
/dev/pts/2
上面的说明第二个终端的设备名是/dev/pts/2,之后再切回到第一个终端,然后
(gdb) tty /dev/pts/2
(gdb)
这样就把我们要调试的程序的输出重定向到第二个终端上了。再切到第二个终端,用sleep语句告诉这个终端,暂时不要做任何事情:
$ sleep 100000
这样就可以保证我们程序的输出不会被打乱,这里选定的时间无所谓,但是要保证在我们调试过程中第二个终端不会“睡醒”。
最后切回gdb,按照正常的调试过程来做就行了,程序的输出都可以在第二个终端上出现。调试完以后,就可以通过ctrl+c来唤醒那个还在沉睡的终端了。
本文参考了:
Using GNU's GDB Debugger Debugging Ncurses Programs