一个WPF和SL的严重BUG,能导致任何的寄主程序崩溃
2011-03-08 14:43
477 查看
先看这个例子,点下这个按钮,你的浏览器一定会崩溃掉。至少在微软修复这个BUG之前会崩溃掉。
经过测试的浏览器有:IE、Chrome、FireFox,其他浏览器,不保证100%崩溃。
重现这个BUG
新建一个SL项目SilverlightApplication1,把MainPage.xaml内容修改为
然后运行。如果你是直接在VS里操作,你会发现VS也一块崩溃了。
我们来分析这个项目。全部都是默认生成的框架,本身没有任何问题。我们只是在MainPage的UserControl里,把自己加入到自己的Context里面。按照逻辑,这个页面会无限的构造下去。这样就导致了“StackOverflowException”。
通常情况下,用户代码的异常都会被 Application_UnhandledException 捕获,并报告给DOM。但是这个异常是在mscorlib.dll产生的,并且(可能)属于 non-CLSCompliant exceptions 导致用户代码不能够捕获到。注:限于本人知识有限,这个假设并不一定正确。
在WPF里,也有类似的BUG
大家可以自行修改代码让WPF也崩溃一次。
现在来看WPF里的另外一个BUG
新建一个任意(非asp.net)项目,并且添加Microsoft.ReportViewer.Common、Microsoft.ReportViewer.WinForms、System.Windows.Forms 和 PresentationFramework 程序集。
Program.cs写入如下代码:
运行后一样的抛出“StackOverflowException”。
如果加上try...catch...语句,效果是一样的,无法捕获到异常。只会在Console得到
如果说这是non-CLSCompliant exceptions那么我们可以配置开启legacyCorruptedStateExceptionsPolicy。
开启后一样会“StackOverflowException”。
至于这是什么状况导致开启了 legacyCorruptedStateExceptionsPolicy 也无法捕获到这个异常,希望有朋友能够帮助大家解答。
或者,这本身就是微软 .NET 框架的 BUG ?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
UPDATE : 感谢朋友们的热情讨论。
对于这个现象,不管说这是程序的BUG还是说这是runtime的BUG,至少这个现象对于使用体验来说是很不利的。谁都不希望使用的时候进程直接崩溃掉,丢失了所有未保存的作业,而不给出任何友好的提示。
但正如 #19 yyww 所说:目前能做到的,只是让你打个日志记录一下。并没有办法改变崩溃的局面。
#21楼 愚溪 的想法很不错。如果说CLR能够在 StackOverflow 和 OutOfMemory 的时候,自动退栈,直到出现catch语句,给开发者一个处理错误的机会,或许程序还能够继续执行。
经过测试的浏览器有:IE、Chrome、FireFox,其他浏览器,不保证100%崩溃。
重现这个BUG
新建一个SL项目SilverlightApplication1,把MainPage.xaml内容修改为
<UserControl x:Class="SilverlightApplication1.MainPage" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns:local="clr-namespace:SilverlightApplication1" > <local:MainPage /> </UserControl>
然后运行。如果你是直接在VS里操作,你会发现VS也一块崩溃了。
我们来分析这个项目。全部都是默认生成的框架,本身没有任何问题。我们只是在MainPage的UserControl里,把自己加入到自己的Context里面。按照逻辑,这个页面会无限的构造下去。这样就导致了“StackOverflowException”。
通常情况下,用户代码的异常都会被 Application_UnhandledException 捕获,并报告给DOM。但是这个异常是在mscorlib.dll产生的,并且(可能)属于 non-CLSCompliant exceptions 导致用户代码不能够捕获到。注:限于本人知识有限,这个假设并不一定正确。
在WPF里,也有类似的BUG
大家可以自行修改代码让WPF也崩溃一次。
现在来看WPF里的另外一个BUG
新建一个任意(非asp.net)项目,并且添加Microsoft.ReportViewer.Common、Microsoft.ReportViewer.WinForms、System.Windows.Forms 和 PresentationFramework 程序集。
Program.cs写入如下代码:
namespace ConsoleApplication1 { class Program { static void Main(string[] args) { System.Windows.Markup.XamlWriter.Save(new Microsoft.Reporting.WinForms.ReportViewer()); } } }
运行后一样的抛出“StackOverflowException”。
如果加上try...catch...语句,效果是一样的,无法捕获到异常。只会在Console得到
Process is terminated due to StackOverflowException.
如果说这是non-CLSCompliant exceptions那么我们可以配置开启legacyCorruptedStateExceptionsPolicy。
<?xml version="1.0"?> <configuration> <runtime> <legacyCorruptedStateExceptionsPolicy enabled="true"/> </runtime> </configuration>
开启后一样会“StackOverflowException”。
至于这是什么状况导致开启了 legacyCorruptedStateExceptionsPolicy 也无法捕获到这个异常,希望有朋友能够帮助大家解答。
或者,这本身就是微软 .NET 框架的 BUG ?
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
UPDATE : 感谢朋友们的热情讨论。
对于这个现象,不管说这是程序的BUG还是说这是runtime的BUG,至少这个现象对于使用体验来说是很不利的。谁都不希望使用的时候进程直接崩溃掉,丢失了所有未保存的作业,而不给出任何友好的提示。
但正如 #19 yyww 所说:目前能做到的,只是让你打个日志记录一下。并没有办法改变崩溃的局面。
#21楼 愚溪 的想法很不错。如果说CLR能够在 StackOverflow 和 OutOfMemory 的时候,自动退栈,直到出现catch语句,给开发者一个处理错误的机会,或许程序还能够继续执行。
相关文章推荐
- Win10正式版开始菜单严重Bug曝光:快捷程序过多或导致崩溃
- VC6 DEBUG版下内存控制的一个BUG,导致debug版程序必将崩溃
- Java nio的一个严重BUG,导致cpu 100%
- linux下由于线程局部存储未初始化导致加载动态链接库时程序崩溃的BUG
- 上万行代码级项目开发中快速定位导致程序崩溃的bug的方法
- [BUG分享]搜狗浏览器地址栏输入特殊字符导致程序崩溃
- Xcode 5 的一个 Bug:修改 TableView的 content导致崩溃
- [ZT]智能ABC一严重Bug可使任意程序崩溃
- QTabWidget bug导致程序崩溃
- 金山毒霸严重BUG导致大量Win7用户系统崩溃
- 解决一个 Websphere 上导致 JVM 崩溃的 bug
- WPF中程序启动时的一个BUG
- 记32位程序(使用3gb用户虚拟内存)使用D3DX9导致的一个崩溃的问题
- 金山毒霸严重BUG再次导致大量Win7/8用户系统崩溃
- Mac 内存被一个叫Installer的程序大量占用导致 内存严重不足 解决方案
- 周末发现一个BUG,时有时无,一出程序就崩溃,郁闷了好久,终于跟出来来了,记之,提醒自己今后一定规范编写,只要规范,绝对不会出问题
- Bug不知道该怎么找?找不到程序崩溃的原因?今天推荐一个第三方的工具
- 一个LoadLibrary导致程序死机的Bug的诊断
- linux下由于线程局部存储未初始化导致加载动态链接库时程序崩溃的BUG
- Xcode 5 的一个 Bug:修改 TableView的 content 导致崩溃