vc下的 oxcccccccc
来源:互联网 发布:巴丁算法 编辑:程序博客网 时间:2024/05/17 07:57
在调试一个程序时,提示出错,看到指针的值为0xcccccccc ,一开始没怎么留意,以为只是一个随机的地址,再看看其它未初始化的指针,也是同样的0xcccccccc ,感觉不对劲,于是上网搜了下,原来还真有其它意思:
第一篇文章(地址:http://www.cppblog.com/tdweng/articles/119404.html )
在VC6下调试程序,可能会遇到诸如指令引用“0xcccccccc ”,该内存不能为Read的报错究其原因,就debug版中的堆栈中的局部变量(包括指针)在明确初始化之前都用0xcc进行初始化,因此,未初始化时候的指针是指向地址 0xcccccccc的,而这段地址一来是处于内核地址空间,一般的应用程序是无权访问的,上面的报错就是这样产生的。因此,一旦遇到上述报错,基本可 以认定程序中出现了野指针。
另外一方面cc对应着int 3调试中断,堆栈中的存放的局部数据一般情况下是只读的,当发生意外执行堆栈里面的数据就会引发该调试中断。
可以认为0x0cc就是有特殊含义的占位符,对于指针而言,它跟NULL是一个意思,其它具有特殊意义的占位符还有:
0xcdcdcdcd - Created but not initialized
0xdddddddd - Deleted
0xfeeefeee - Freed memory set by NT's heap manager
0xcccccccc - Uninitialized locals in VC6 when you compile w/ /GZ
0xabababab - Memory following a block allocated by LocalAlloc()
第二篇文章(地址:http://blog.csdn.net/liufei_learning/archive/2010/04/18/5498687.aspx ):
在VC Debug版本里,栈中分配的值都会先用0xCCCCCCCC来处理一下,所以大家在Debug模式下调试程序发现在引用0xCCCCCCCC这样的值, 就说明在试图使用一个没有初始化的值。这就是在Debug模式下调试的好处之一,如果在Release模式下,系统就不会用0xCCCCCCCC来处理一 下了。至于为什么选择0xCCCCCCCC大概是因为端点中断int 3 对应的机器码就是0xCC吧。
用固 定的地址是可以访问指针所指向的数据的。但是在一般情况下,Windows可能会报非法操作。[b]
VC的DEBUG版会把未初始化的指针自动初始化为0xCCCCCCCC,而不是就让它随机去,那是因为DEBUG版的目的是为了方便我们调试程序的,如 果野指针的初值不确定,那么每次调试同一个程序就可能出现不一样的结果,比如这次程序崩掉,下次正常运行,再一次虽然没崩掉,但结果不对……那显然对我们解bug是非常不利的。 [b]DEBUG版本为了能让程序员更早的发现错误,把堆栈上的数据对初始化成了0xcc,也就是说局部变量如果不初始化,那么DEBUG版本中就会是0xCC。[b] Debug为了调试方便,也就是其Edit And Continue特性,为每个函数都多分配了64个字节。当用户在调试时在代码里增加少量变量的时候,编译器就可以分配那64个字节的空间过去,这样就不用重新编译程序来重新调试。
以前真的未留意这些细节问题,可能是程序写得少吧,以后要注意点才行了。不过两篇文章里面都提到的 堆栈中的局部变量(包括指针)在明确初始化之前都用0xcc进行初始化,这点我实际调试的时候倒没有这种现象,只有指针是。
第一篇文章(地址:http://www.cppblog.com/tdweng/articles/119404.html )
在VC6下调试程序,可能会遇到诸如指令引用“0xcccccccc ”,该内存不能为Read的报错究其原因,就debug版中的堆栈中的局部变量(包括指针)在明确初始化之前都用0xcc进行初始化,因此,未初始化时候的指针是指向地址 0xcccccccc的,而这段地址一来是处于内核地址空间,一般的应用程序是无权访问的,上面的报错就是这样产生的。因此,一旦遇到上述报错,基本可 以认定程序中出现了野指针。
另外一方面cc对应着int 3调试中断,堆栈中的存放的局部数据一般情况下是只读的,当发生意外执行堆栈里面的数据就会引发该调试中断。
可以认为0x0cc就是有特殊含义的占位符,对于指针而言,它跟NULL是一个意思,其它具有特殊意义的占位符还有:
0xcdcdcdcd - Created but not initialized
0xdddddddd - Deleted
0xfeeefeee - Freed memory set by NT's heap manager
0xcccccccc - Uninitialized locals in VC6 when you compile w/ /GZ
0xabababab - Memory following a block allocated by LocalAlloc()
第二篇文章(地址:http://blog.csdn.net/liufei_learning/archive/2010/04/18/5498687.aspx ):
在VC Debug版本里,栈中分配的值都会先用0xCCCCCCCC来处理一下,所以大家在Debug模式下调试程序发现在引用0xCCCCCCCC这样的值, 就说明在试图使用一个没有初始化的值。这就是在Debug模式下调试的好处之一,如果在Release模式下,系统就不会用0xCCCCCCCC来处理一 下了。至于为什么选择0xCCCCCCCC大概是因为端点中断int 3 对应的机器码就是0xCC吧。
用固 定的地址是可以访问指针所指向的数据的。但是在一般情况下,Windows可能会报非法操作。[b]
VC的DEBUG版会把未初始化的指针自动初始化为0xCCCCCCCC,而不是就让它随机去,那是因为DEBUG版的目的是为了方便我们调试程序的,如 果野指针的初值不确定,那么每次调试同一个程序就可能出现不一样的结果,比如这次程序崩掉,下次正常运行,再一次虽然没崩掉,但结果不对……那显然对我们解bug是非常不利的。 [b]DEBUG版本为了能让程序员更早的发现错误,把堆栈上的数据对初始化成了0xcc,也就是说局部变量如果不初始化,那么DEBUG版本中就会是0xCC。[b] Debug为了调试方便,也就是其Edit And Continue特性,为每个函数都多分配了64个字节。当用户在调试时在代码里增加少量变量的时候,编译器就可以分配那64个字节的空间过去,这样就不用重新编译程序来重新调试。
以前真的未留意这些细节问题,可能是程序写得少吧,以后要注意点才行了。不过两篇文章里面都提到的 堆栈中的局部变量(包括指针)在明确初始化之前都用0xcc进行初始化,这点我实际调试的时候倒没有这种现象,只有指针是。
- vc下的 oxcccccccc
- VC下的打印
- VC下的BOOL
- VC下的时间
- VC下的nmake
- VC下打印机的使用
- VC下CheckListBox的创建
- VC下的函数地址
- VC下的基本字处理
- VC下的链接库
- VC++ 下编码的转换
- VC++下ODBC的编程
- VC下打印机的使用
- vc下opencv的配置
- vc下的时间格式化
- VC++ 下编码的转换
- VC++下的Unicode编程
- VC下的 PEEK POKE
- Spring MVC 教程,快速入门,深入分析
- Runtime.getRuntime().exec()执行linuxshell脚本
- C++入门必用:C++ 程序设计教程资料集
- 对话框中设置静态文本框字体及颜色
- Notepad++删除空白行
- vc下的 oxcccccccc
- struts2.3.8 配置教程
- Android应用程序如何访问/sys和/proc等目录下的系统文件
- 我的2012----苦逼程序员的蜕变
- 16进制与float互转
- 杭电ACM 2037 今年暑假不AC
- windows下进程间通信的手段有哪些?
- IBM DS5020 Econfig 配置举例 600GB SAS硬盘
- shadowView.alpha = 0.; // alpha 是 0 时候,在 shadowView 后面的 视图还是能拖动的! 为啥么