单步 Debug 是一个非常有效的代码调试手段。对于发现代码中的问题非常有帮助。
Debug 的基本功能有:
1按行,按过程(函数),按次数(循环),按条件执行程序。
2在特定条件下暂停程序。并可观察到此时刻的所有变量值。且可以随时修改变量值。
比如:
Program Main
Implciit None
Do i = 1 , 10000000
一些代码
y = f( i )
另一些代码
End Do
End Program
这段代码出错了。可你并不知道为什么。你就可以在 Do 开始的地方下断点,运行到此处。
然后一次一次的检查,看代码是在哪儿出错的。
假设循环 1 到 10000000,到第 3567 次出错了。你还可以设置条件断点,或者直接改变 i 的值,使得 i 直接等于 3567。
(当然,要结合你的算法,看直接改变 i 是否合适)
你可以通过 debug 做的事情还有很多。。。。。
可以说,debug 是一个程序员的基本功。
**箭头应该是指:当前执行到了该行。
用户断点(其实你也许没有设置这个)
这个信息告诉我们,程序中某个地方已经开始溃烂,如果你频繁的碰到这个对话框,就说明溃烂已经扩大了。
如果你够仔细,你会发现在你点了这个对话框的确定按钮之后,会在Output窗口中发现多了一行信息:
HEAP[DebugInfo2exe]: Heap block at 00030FD8 modified at 00031010 past requested size of 30
查看堆栈窗口,里面显示这样的信息:
NTDLL! 7c921230()
NTDLL! 7c97db9c()
NTDLL! 7c98cd11()
NTDLL! 7c980af8()
KERNEL32! 7c85e7af()
_CrtIsValidHeapPointer(const void 0x00031000) line 1697
_free_dbg(void 0x00031000, int 0x00000001) line 1044 + 9 bytes
operator delete(void 0x00031000) line 49 + 16 bytes
WinMain(HINSTANCE__ 0x00400000, HINSTANCE__ 0x00000000, char 0x00151f15, int 0x00000001) line 13 + 15 bytes
WinMainCRTStartup() line 198 + 54 bytes
KERNEL32! 7c816d4f()
重现这样的现场很容易的,只需几行代码就可以了
char p = new char[4];
lstrcpy(p, "this is a test");
delete p;
为什么会有这样的信息消息框出现呢?这是因为如果我们在调试状态下, *** 作系统用DebugWin32Heap来替代正常的heap分配内存空间。在这个堆上的任何 *** 作,debug的堆管理器会检查堆的数据完整性,如果它发现了一个错误,就会报告一个消息上来。
那么,我们怎么样才能知道造成错误的原因呢?如果只是类似上面的演示代码,不用任何技巧都能发现并且定位的。但是,绝大多数情况下,Output窗口和CallStack窗口告诉我们的信息都不能让我们精确定位。
用BoundsChecker做运行期的检查可以查到这个错误的原因,并且我个人认为在程序发布之前,在BoundsChecker下完整的跑一遍,检查内存和资源是非常有必要的。但是每次都用BoundsChecker是比较麻烦的。
还有一个办法,可以让这种定位更准确一点。
那就是windows 2000 SP2之后提供的PageHeap机制。
下面的这段文字是别人写的,我抄的,:)
当一个应用程序的PageHeap机制被激活时,该应用程序的所有的堆分配被放到内存中,这样堆的边界就与虚拟内存的边界排在一起了。与堆相邻的虚拟内存页面被设置为NO_ACCESS。在该应用程序中对堆后面的空间的访问就会立刻引起错误,这就可以在一个调试工具中被捕获。在释放堆时,过程与之类似。PageHeap修改释放的应用程序虚拟页面为NO_ACCESS,这样,如果应用程序试图读写该内存时就会发生访问错误。如果为一个应用程序运行PageHeap特性,应用程序要比正常时运行得慢,并且需要更多的虚拟内存,因为每一个堆的分配都需要两个完整的虚拟内存页面。随着应用程序对堆的使用的增加,可能需要增加系统的虚拟内存的大小,否则会出现虚拟内存不够的错误信息。除非系统有相当大的虚拟内存,否则建议不要同时运行两个以上的激活了PageHeap特性的应用程序。
让我们的程序启用Full Page Heap机制,只需在注册表中
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourAppNameexe下增加如下设置:
GlobalFlag,字符串类型,值是x02200000
PageHeapFlags,字符串类型,值是0x3
VerifierFlags,DWORD类型,值是00000001
其中YourAppNameexe换成你的程序的名字,不要带路径。
如果嫌麻烦,你可以到>
你查看局部变量的时候,中断点是不是设在了12前面?如果是的话,sum的值肯定没有变化,因为程序没有运行到这一行,而就你给出的这段代码看不出什么问题,所以,请查查看其它部分有没有错?或贴上来更多的代码
"中断无可用源"错误通常会出现在Fortran代码中,这是因为系统或程序正在尝试访问一个不存在或已经被删除的中断源或事件。这种情况可能由以下原因导致:
1 在配置硬件时未正确定义中断源。
2 外部设备引发中断,但由于没有注册或初始化该中断,因此无法正常处理中断源。
3 中断源已被禁用或被其他 *** 作占用。
4 可能是因为程序所运行的环境不支持中断。
要解决这个错误,可以考虑对应的中断源是否存在、是否已经定义和初始化中断等检查,以确保程序正确地响应中断事件。此外,你还可以检查代码中关于中断的配置和 *** 作是否正确,并确认在当前环境中是否支持使用中断。另外,也可以尝试使用调试工具来定位该错误,并进行修复。
类似的情形,就是调试器已经无法切中需要的断点。
原因,一种是调试器本身的缺陷,遇到为预见的情形,没有相应的处理逻辑可循;另一种是编译器本身的缺陷,导致编译过程产生错误的代码,且没有给出提示。
解决的办法不多。建议可以在程序代码中插入语句,人为输出一些标志和中间变量,帮助追踪出错的语句。
例如,在循环中插入输出循环变量的语句,以观察出错的发生的位置和相应的循环变量值。
又如,在有疑点的语句前后,插入带标志的stop,如stop ‘abc',以便快速定位问题语句。
通过上述方法找到问题,避免调试失败后,便可以进入正常的调试。
如果是win程序,可以将上述输出的信息定向输出到文件,以不影响程序界面的正常显示。
供您参考。
首先如果能编译运行成功,说明程序本身并没有问题。
其次变量有可能被定义在模块中,这样就相当于全局变量一样,看不到具体的数值
第三你可以用write看看能不能输出数值,从而判断程序有没有错误
以上就是关于fortran 单步调试全部的内容,包括:fortran 单步调试、运行fortran时候,出现【user breakpoint called from code at ox75091946】这种提示,怎么办、求助一段fortran代码,老显示中断。。。等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)