又一个悬而未决的bug被解决
2016-10-19 10:50
429 查看
之所以叫悬而未决,是因为从我第一次见到这个bug,到现在大概已经过了快两年的时间,期间好几次想解决这个问题,但是一直碍于环境和一些技术上的限制,没有解决,直到昨天在一系列的因素作用下,终于解决了这个问题。
还是从头来说说这个bug吧,这个bug在网络上从未见过,一直以来搜索都没有找到有价值的资料,在我心里一直是个幽灵般的存在。
bug的出现是在Windows 7 SP1的系统上安装了一个遗留的VB编写的老系统之后出现的(之所以能确定和这个系统,是和另外一个同事有关,我一直以为只有我能遇到这个幽灵bug,但是他安装了老系统之后也出现了一模一样的问题,从那以后才锁定了bug的元凶,可惜到解决问题也不清楚到底老系统在里面扮演了什么样的角色,导致了这个问题出现)。
最初bug的症状是SQL Server 2008 R2的SSMS(SQL Server Management Studio)出现了无法查询数据的错误(任意选择任意数据库的任意表,在右键菜单中选择“选择前1000行”),当时的感觉就是疥癣之疾,因为不能查询,但是可以编辑(数据表右键菜单中的“编辑前200行”),可以曲线救国达到查询数据的目的,也就没太上心。
直到有一天在查看windows事件日志的时候居然也报这个错误,觉得实在是是可忍孰不可忍,所以开始搜索所有一切和这个问题有关的信息,如前所说,网络上没有太多有价值的信息,当时找到的一篇微软博客上的资料算是最接近的,
Easily Resolving an Event Viewer Error using a Process Memory Dump http://blogs.msdn.com/b/ntdebugging/archive/2009/02/16/easily-resolving-an-event-viewer-error-using-a-process-memory-dump.aspx 提供的思路是dump出内存转储进行分析,虽然我对分析内存转储并不熟,但是当时抱着学习的想法就照着这个思路去做,结果去dump SSMS的内存转储,结果又提示没有权限,当时的感觉是天塌地陷,没路可走了,于是又开始了好长一段时间不再管它。
后来就是另外一个同事确定了bug的元凶,但是这对解决问题并没太帮助,那次又花了几个小时去尝试解决这个问题,可惜还是无功而返。
说了这么久,再来聊聊这个bug本身,从一直以来的分析和函数堆栈可以得知是在DateTime格式化的时候出的问题,
简单的说就是这样一行代码会抛出FormatException:String str = DateTime.Now.ToString();
但是这个问题并不会在我们自己的项目中出现,当时我一直没注意这一点,直到解决这个问题之后才想到这也是一个点。
最后还是回到如何解决这个问题上来吧,昨天晚上机缘巧合看到了这个:
可在广域网部署运行的QQ高仿版 -- GGTalk总览
http://www.cnblogs.com/justnow/p/3382160.html
然后就下载了源代码,想编译看看,结果如大家所想的那样,我又碰上了这个问题,不过这次是在有源代码的情况下还碰上这个问题,我的牛劲又上来了,还就不相信了,有源代码还揪不出来你个小样
于是我跟踪了代码,最终确定了的确是在上面那行代码上出问题,有人也许会问难道这么久你在自己的项目都没碰到过这个问题么,的确,我也这么写过,但还真没碰到过,为什么?
原来出问题的.NET Framework是2.0版本,我试了4.0版本,即使在有问题的计算机上也不会出现这个异常,猜测是4.0的代码中加入异常处理,如果有异常抛出的话会格式化成默认的格式。
确定了问题之后也解决不了啊,不是在自己的代码出的问题,这下就看出开源的好处了,微软不是公开了.NET Framework的代码么,咱上代码看!
细节就不多说了,可惜的是现在直接看不到2.0的代码,就拿4.6.1的来看了,想着这些基本类库里面的改动应该不会特别大,希望能有帮助
跟踪的过程也不细说了,直到看到下面这个属性终于找到对解决问题有帮助的内容(其实在之前就怀疑和区域的时间设置有关系,不过因为平时做这方面的工作不多,对类库不熟)
public static DateTimeFormatInfo CurrentInfo {
get {
Contract.Ensures(Contract.Result<DateTimeFormatInfo>() != null);
System.Globalization.CultureInfo culture = System.Threading.Thread.CurrentThread.CurrentCulture;
if (!culture.m_isInherited) {
DateTimeFormatInfo info = culture.dateTimeInfo;
if (info != null) {
return info;
}
}
return (DateTimeFormatInfo)culture.GetFormat(typeof(DateTimeFormatInfo));
}
}
接下来就是查看出问题的程序的区域文化信息,终于找到问题的根源,不知道为什么FullDateTimePattern等几个属性的值居然有乱码,但是在系统的区域属性当中查看却是没有乱码的(也许是系统自行处理这些异常?)
知道了问题根源,怎么解决也就不那么困难了,到系统的区域设置当中重置自定义格式,之后世界清静了,呼!
还是从头来说说这个bug吧,这个bug在网络上从未见过,一直以来搜索都没有找到有价值的资料,在我心里一直是个幽灵般的存在。
bug的出现是在Windows 7 SP1的系统上安装了一个遗留的VB编写的老系统之后出现的(之所以能确定和这个系统,是和另外一个同事有关,我一直以为只有我能遇到这个幽灵bug,但是他安装了老系统之后也出现了一模一样的问题,从那以后才锁定了bug的元凶,可惜到解决问题也不清楚到底老系统在里面扮演了什么样的角色,导致了这个问题出现)。
最初bug的症状是SQL Server 2008 R2的SSMS(SQL Server Management Studio)出现了无法查询数据的错误(任意选择任意数据库的任意表,在右键菜单中选择“选择前1000行”),当时的感觉就是疥癣之疾,因为不能查询,但是可以编辑(数据表右键菜单中的“编辑前200行”),可以曲线救国达到查询数据的目的,也就没太上心。
直到有一天在查看windows事件日志的时候居然也报这个错误,觉得实在是是可忍孰不可忍,所以开始搜索所有一切和这个问题有关的信息,如前所说,网络上没有太多有价值的信息,当时找到的一篇微软博客上的资料算是最接近的,
Easily Resolving an Event Viewer Error using a Process Memory Dump http://blogs.msdn.com/b/ntdebugging/archive/2009/02/16/easily-resolving-an-event-viewer-error-using-a-process-memory-dump.aspx 提供的思路是dump出内存转储进行分析,虽然我对分析内存转储并不熟,但是当时抱着学习的想法就照着这个思路去做,结果去dump SSMS的内存转储,结果又提示没有权限,当时的感觉是天塌地陷,没路可走了,于是又开始了好长一段时间不再管它。
后来就是另外一个同事确定了bug的元凶,但是这对解决问题并没太帮助,那次又花了几个小时去尝试解决这个问题,可惜还是无功而返。
说了这么久,再来聊聊这个bug本身,从一直以来的分析和函数堆栈可以得知是在DateTime格式化的时候出的问题,
简单的说就是这样一行代码会抛出FormatException:String str = DateTime.Now.ToString();
但是这个问题并不会在我们自己的项目中出现,当时我一直没注意这一点,直到解决这个问题之后才想到这也是一个点。
最后还是回到如何解决这个问题上来吧,昨天晚上机缘巧合看到了这个:
可在广域网部署运行的QQ高仿版 -- GGTalk总览
http://www.cnblogs.com/justnow/p/3382160.html
然后就下载了源代码,想编译看看,结果如大家所想的那样,我又碰上了这个问题,不过这次是在有源代码的情况下还碰上这个问题,我的牛劲又上来了,还就不相信了,有源代码还揪不出来你个小样
于是我跟踪了代码,最终确定了的确是在上面那行代码上出问题,有人也许会问难道这么久你在自己的项目都没碰到过这个问题么,的确,我也这么写过,但还真没碰到过,为什么?
原来出问题的.NET Framework是2.0版本,我试了4.0版本,即使在有问题的计算机上也不会出现这个异常,猜测是4.0的代码中加入异常处理,如果有异常抛出的话会格式化成默认的格式。
确定了问题之后也解决不了啊,不是在自己的代码出的问题,这下就看出开源的好处了,微软不是公开了.NET Framework的代码么,咱上代码看!
细节就不多说了,可惜的是现在直接看不到2.0的代码,就拿4.6.1的来看了,想着这些基本类库里面的改动应该不会特别大,希望能有帮助
跟踪的过程也不细说了,直到看到下面这个属性终于找到对解决问题有帮助的内容(其实在之前就怀疑和区域的时间设置有关系,不过因为平时做这方面的工作不多,对类库不熟)
public static DateTimeFormatInfo CurrentInfo {
get {
Contract.Ensures(Contract.Result<DateTimeFormatInfo>() != null);
System.Globalization.CultureInfo culture = System.Threading.Thread.CurrentThread.CurrentCulture;
if (!culture.m_isInherited) {
DateTimeFormatInfo info = culture.dateTimeInfo;
if (info != null) {
return info;
}
}
return (DateTimeFormatInfo)culture.GetFormat(typeof(DateTimeFormatInfo));
}
}
接下来就是查看出问题的程序的区域文化信息,终于找到问题的根源,不知道为什么FullDateTimePattern等几个属性的值居然有乱码,但是在系统的区域属性当中查看却是没有乱码的(也许是系统自行处理这些异常?)
知道了问题根源,怎么解决也就不那么困难了,到系统的区域设置当中重置自定义格式,之后世界清静了,呼!
相关文章推荐
- 解决了日志摘要的一个小bug,并增加了新功能
- 今天发现一个非常奇怪的VSIDE BUG,经过1个小时的研究解决
- Visual C++6.0一个小BUG的解决方法
- asp.net的一个bug的发现和解决
- Linux 2.4.18的内核在使用S3C2410板的USB设备时碰到的一个Bug的解决办法
- J2ME中一个奇怪的BUG及其解决方法
- 通过event对象的fromElement属性解决热区设置主实体的一个bug
- Visual C++6.0一个小BUG的解决方法
- wxPython 2.8.7.1版本的一个严重BUG和解决方法
- Visual C++6.0一个小BUG的解决方法
- 博客园 FreeTextBox 还有一个 bug, 请 dudu 解决一下
- [ASP.NET 2.0]PageParser.GetCompiledPageInstance中的一个Bug及解决方法
- 用递归算法解决VC中CEdit的一个Bug
- 探讨C#.NET下DropDownList的一个有趣的bug及其解决办法
- 解决一个 Websphere 上导致 JVM 崩溃的 bug
- 用递归算法解决VC中CEdit的一个Bug
- QQ登录没反应解决方法,及新版QQ的一个BUG
- VS2005中的一个小BUG:关于Dropdownlist无法Datadinding的解决方法。
- 通过event对象的fromElement属性解决热区设置主实体的一个bug
- 通过event对象的fromElement属性解决热区设置主实体的一个bug