hur.cn - 华软网

 热门搜索

选择Debug模式编译出的程序总是出Debug Assertion Failed异常,而选择Release却无法正确编译?

  作者:未知    来源:网络    更新时间:2011/2/10
写好一个程序后,想编译成.exe文件,
当选择Debug模式时,可以正确编译出.exe文件,
但是,当运行这个程序时,却时常出现Debug Assertion Failed这个异常,并弹出窗口说在xxx行有错误之类……
经常遇到这种情况,很是郁闷,,,,


baidu/google咨询说用Release模式编译可以去除这些异常,
于是选择Release模式编译,却出现了很多错误,根本就无法编译,

这是怎么回事??

为什么同样一段程序用Debug和Release模式编译会出现如此大的差异呢?
---华软 网友回答---
你要在Debug模式中定位下是哪里出问题了,改变编译模式不是解决问题的根本途径
---华软网友回复---
如何定位?

用Debug模式编译出的exe程序会出现异常错误,但不是经常,是偶尔,
频率非常低,比如,做同样的操作,可能半个月才会出现一次这样的错误(当然,半个月内一直在使用:),
所以用F5调试根本就很难发现,
---华软网友回复---
从网上找来这么一段方法:
-----------------------------
首先如果你用的是vc6的话:
1。按F5运行你的程序
2。在出错时,选择“重试”
3。按ALT+7调出“调用栈”窗口
4。双击从上往下的最近一个自己定义的函数,系统会自动把该函数所在的文件显示出来,此时程序就暂停在光标处。一般来说错误就出在这附近。你可以通过查看变量的值来确认
---华软网友回复---
比较debug与release配置的区别!
---华软网友回复---
引用 4 楼 fandh 的回复:
比较debug与release配置的区别!

你是指查看代码中_DEBUG部分都有什么内容吗?
---华软网友回复---
断言错误,可以调试哈
---华软网友回复---
debug模式下assert异常可以找到是哪一行代码除了问题,如果这一行代码是你写的,错误就找到了,前提是你在可能出问题的代码中用了assert。


    应该认真分析一下debug模式下Debug Assertion Failed究竟是发生在哪儿?
    此外,需要明确release出现的是编译错误,还是连接错误,如果是连接错误,很可能是两种模式的配置不同,比如说包含的库文件可能不同。如果是编译错误,那很可能是#ifdef _DEBUG 之类的宏引起的。
    
---华软网友回复---
应该算是编译错误吧。。。
C++">
1>Compiling...
..........
xxx.h(43) : error C2440: 'default argument' : cannot convert from 'const wchar_t [5]' to 'const char *'
1>        Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
.............
: error C2440: 'initializing' : cannot convert from 'const char [3]' to 'ATL::CStringT<BaseType,StringTraits>'
1>        with
1>        [
1>            BaseType=wchar_t,
1>            StringTraits=StrTraitMFC_DLL<wchar_t>
1>        ]
1>        Constructor for class 'ATL::CStringT<BaseType,StringTraits>' is declared 'explicit'
1>        with
1>        [
1>            BaseType=wchar_t,
1>            StringTraits=StrTraitMFC_DLL<wchar_t>
1>        ]
..............

都是这种错误,

---华软网友回复---
debug都有问题,就不用release了
---华软网友回复---
引用 8 楼 abcdwell 的回复:
应该算是编译错误吧。。。

C/C++ code

1>Compiling...
..........
xxx.h(43) : error C2440: 'default argument' : cannot convert from 'const wchar_t [5]' to 'const char *'
1>        Types pointed to are unrela……

工程属性比较下debug和release有用到unicode了吗?另一个没有用。
---华软网友回复---
引用 9 楼 jennyvenus 的回复:
debug都有问题,就不用release了

debug编译链接都没有问题,可以正常生成exe,但是,运行时偶尔会出现异常,

用release编译时会出现如7楼所示的错误,
---华软网友回复---
仔细查看。。。。。。。。。。
---华软网友回复---
引用 10 楼 eyey1 的回复:
工程属性比较下debug和release有用到unicode了吗?另一个没有用。

没错,的确是这样,
在release模式下:
Use Unicode Character Set时就会出现如我8楼所示错误,
Use Multi-Byte Character Set时则不会出现错误。
---华软网友回复---
在release模式下,Use Multi-Byte Character Set时则不会出现错误,可以正常编译成功,
生成.exe文件,
是不是这样就可以避免出现Debug Assertion Failed异常了呢?
---华软网友回复---
引用 13 楼 abcdwell 的回复:
引用 10 楼 eyey1 的回复:
工程属性比较下debug和release有用到unicode了吗?另一个没有用。

没错,的确是这样,
在release模式下:
Use Unicode Character Set时就会出现如我8楼所示错误,
Use Multi-Byte Character Set时则不会出现错误。

release改成Use Multi-Byte Character Set。
---华软网友回复---
强制release早晚也会有问题,都已经提示出XX行有问题了,还不赶快解决。
---华软网友回复---
引用 14 楼 abcdwell 的回复:
在release模式下,Use Multi-Byte Character Set时则不会出现错误,可以正常编译成功,
生成.exe文件,
是不是这样就可以避免出现Debug Assertion Failed异常了呢?

是的,Debug Assertion Failed异常是由ASSERT()等宏引起的,debug下用来方便调试,排除bug,release下不起作用。
虽然不出现Debug Assertion Failed异常了,但可能出现更大的问题。比如ASSERT判断一个指针是否为空,空就不执行了,抛出异常,但release下可能要访问这个空指针了,会导致内存访问违例,就是崩掉了。
---华软网友回复---
引用 16 楼 jennyvenus 的回复:
强制release早晚也会有问题,都已经提示出XX行有问题了,还不赶快解决。

呵呵,谢谢提醒,

他提示的是什么wincore.cpp中xxx行有错误,
说实话,还真不知道该如何解决,
---华软网友回复---
debug下如果出现了断言错误,而且这个断言错误却不是经常出现,就应当确定为有多线程同步问题,或者引用了第三方库。楼主应该在断言失败时,选择重试,使得程序执行流程回到断言失败处,查看一些变量和堆栈信息。
debug下的问题不解决,release的风险是很大的。
---华软网友回复---
先Debug调试吧,先定位错误的函数调用的地方
---华软网友回复---
引用 19 楼 bai_hua_lin 的回复:
debug下如果出现了断言错误,而且这个断言错误却不是经常出现,就应当确定为有多线程同步问题,或者引用了第三方库。楼主应该在断言失败时,选择重试,使得程序执行流程回到断言失败处,查看一些变量和堆栈信息。
debug下的问题不解决,release的风险是很大的。

有道理,的确有线程使用,
---华软网友回复---
什么.cpp 有错的那种,都是在vc安装目录下的。

---华软网友回复---
用call stack窗口看看。
---华软网友回复---
引用 23 楼 eyey1 的回复:
用call stack窗口看看。

谢谢,我也想用Call Stack看看,但是,之前也说过,没法看,

一般情况下都不出异常,只有在用户使用时才会偶尔出现,
---华软网友回复---
引用 22 楼 jennyvenus 的回复:
什么.cpp 有错的那种,都是在vc安装目录下的。

啥意思,大哥?!

俺知道wincore.cpp是在vc安装目录下,但这有什么用呢?

请明示,谢谢!
---华软网友回复---
    我的建议:
    第一、在debug模式下调试,每次试运行用F5.当出现assert异常时,程序会停止在出现错误的代码行。此时通过VC的调试窗口,查看一下各个局部变量、成员变量等等是否和预期的值相等。很有可能是某个指针无效或者为空。
    第二、可以使用TRACE语句,在可能出错的地方把重要的变量打印出来。如果在release模式下,TRACE会失效,可以使用OutputDebugString函数,效果一样。问题解决后将这些调试语句注视掉即可。
    
    总之,一定要先搞定debug;试运行一定要用F5,尤其是随机出现的错误。
    出现assert异常恰恰说明错误明显,容易找到。如果突然间蹦出个栈溢出、内存访问异常,找起来就费劲了。认真查找代码漏洞吧,会成功的。
---华软网友回复---
其实为了解决这种问题,俺就不用ASSERT宏,全部用if搞定。

---华软网友回复---
引用 27 楼 jennyvenus 的回复:
其实为了解决这种问题,俺就不用ASSERT宏,全部用if搞定。

真不厚道,咋不早说呢?!
---华软网友回复---
谢谢jennyvenus,试试你的方法,


---华软网友回复---
谢谢stephen_young!!!
---华软网友回复---
引用 21 楼 abcdwell 的回复:
引用 19 楼 bai_hua_lin 的回复:
debug下如果出现了断言错误,而且这个断言错误却不是经常出现,就应当确定为有多线程同步问题,或者引用了第三方库。楼主应该在断言失败时,选择重试,使得程序执行流程回到断言失败处,查看一些变量和堆栈信息。
debug下的问题不解决,release的风险是很大的。

有道理,的确有线程使用,


把一些重要变量的值保存到文件中,出问题时,通过文件分析这些变量。对于一些被几个地方修改的变量,考虑一些同步问题,设置一些同步互斥访问的机制。
---华软网友回复---

---华软网友回复---
  class="deleted_message"> 该回复于2011-03-11 11:14:21被版主删除
---华软网友回复---
我是这样解决的:(VC++6.0)
"Project"->"setting"->"点击c/c++"->"Category选项中选择Preprocessor"
->"在Undefined symbols:填写_DEBUG" 重新编译运行即可
---华软网友回复---
zyx89513
非常感谢      
华软声明:本内容来自网络,如有侵犯您版权请来信指出,本站立即删除。