String.IsNullOrEmptyOr... NullRefererenceException!
-
If it's seriously affecting you, and you want a hotfix, you have to call Microsoft support. That's the way they work. The Connect site is for reporting problems in the current or beta/CTP versions that you don't need an immediate fix for. Don't necessarily expect it to appear in a service pack, either; they're normally simply collections of hotfixes requested by customers, unless it's an issue they've experienced internally. In this particular case, since '.NET Framework 3.5' will still run on the .NET 2.0 CLR, Microsoft are producing an SP1 for .NET 2.0 which should include this fix. If Microsoft determine that a bug can only be fixed by providing a hotfix, you will normally get the cost of your call/the support incident refunded. For this, however, there's an obvious workaround - test for
nullexplicitly rather than usingIsNullOrEmpty.Stability. What an interesting concept. -- Chris Maunder
Mike Dimmick wrote:
however, there's an obvious workaround - test for null explicitly rather than using IsNullOrEmpty
Uhh.. in thousands of lines of code in a released application that is working perfectly so far. No thanks on that one!
"110%" - it's the new 70%
-
:omg::wtf: I think that I need say nothing... :doh: Serious bug in String.IsNullOrEmpty in the .NET 2.0 CLR[^] Null Exemption caused by JIt optimisation around String.IsNullOrEmpty[^] Corrections?
This bug has now been fixed in the Orcas CLR. The fix should be available in the next Orcas CTP.
Thanks again,
CLR JIT Team:omg::wtf:
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
I can't find any official Microsoft bug document for this. I've got a very large app that uses that method *very* widely and no reports of this problem at all. Is this just fear mongering or is there a legitimate document from Microsoft confirming this problem in the form of one of their bug documents?
"110%" - it's the new 70%
-
I can't find any official Microsoft bug document for this. I've got a very large app that uses that method *very* widely and no reports of this problem at all. Is this just fear mongering or is there a legitimate document from Microsoft confirming this problem in the form of one of their bug documents?
"110%" - it's the new 70%
The second link that I provided is from Microsoft Connect website: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=113102[^]
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
The second link that I provided is from Microsoft Connect website: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=113102[^]
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
It's opening fine here... Try the google cache: http://216.239.51.104/search?q=cache:lDYmQBlaxZ0J:connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx%3FFeedbackID%3D113102+http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx%3FFeedbackID%3D113102&hl=en&ct=clnk&cd=1&client=firefox-a[^]
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
It's opening fine here... Try the google cache: http://216.239.51.104/search?q=cache:lDYmQBlaxZ0J:connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx%3FFeedbackID%3D113102+http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx%3FFeedbackID%3D113102&hl=en&ct=clnk&cd=1&client=firefox-a[^]
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
:rolleyes: So you have a cache of a user submitted bug report from 2006 that has since been removed from the connect site? I thought you were reporting a confirmed, serious problem that would have a microsoft knowledgebase article and id number. This all seems pretty tenuous. You had me worried when I first read the original post, now I doubt it's even real.
"110%" - it's the new 70%
-
:rolleyes: So you have a cache of a user submitted bug report from 2006 that has since been removed from the connect site? I thought you were reporting a confirmed, serious problem that would have a microsoft knowledgebase article and id number. This all seems pretty tenuous. You had me worried when I first read the original post, now I doubt it's even real.
"110%" - it's the new 70%
The feedback id is 113102. And opens fine to me (the original, not the cache. The cache I gave you for courtesy). The fact of the report is from 2006 just turn yet bad the problem, because MS says that will fix it only in Orcas release!
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
The feedback id is 113102. And opens fine to me (the original, not the cache. The cache I gave you for courtesy). The fact of the report is from 2006 just turn yet bad the problem, because MS says that will fix it only in Orcas release!
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
-
:omg::wtf: I think that I need say nothing... :doh: Serious bug in String.IsNullOrEmpty in the .NET 2.0 CLR[^] Null Exemption caused by JIt optimisation around String.IsNullOrEmpty[^] Corrections?
This bug has now been fixed in the Orcas CLR. The fix should be available in the next Orcas CTP.
Thanks again,
CLR JIT Team:omg::wtf:
For God so loved the world, that he gave his only begotten Son, that whosoever believeth in him should not perish, but have everlasting life.(John 3:16) :badger:
Huh, I can't reproduce it.
-
Well, until I see a bug report *from microsoft* I'm going to have to rely on my personal experience and call this either a myth or so rare as to be not an issue in any practical sense.
"110%" - it's the new 70%
It's not a myth. For reference, here is the repro code: static void Main(string[] args) { Console.WriteLine("starting"); test(null); Console.WriteLine("finished"); Console.ReadLine(); } static void test(string x) { for (int j = 0; j < 10; j++) { if (String.IsNullOrEmpty(x)) { //TODO: } } } Note that it's a very specific circumstance. You have to be running the code in a tight loop to exercise the buggy JIT optimization. Note also that because this is a JIT bug, you have to compile the code and run it from the command line. Optimization is automatically disabled for programs launched from the Visual Studio IDE, even in release mode. Also remember that you need the .NET Framework 2.0 installed to exercise this. So the bug is in the optimizer itself - potentially serious, I guess. I've not heard of anybody actually being affected by this in a production app though.
-
It's not a myth. For reference, here is the repro code: static void Main(string[] args) { Console.WriteLine("starting"); test(null); Console.WriteLine("finished"); Console.ReadLine(); } static void test(string x) { for (int j = 0; j < 10; j++) { if (String.IsNullOrEmpty(x)) { //TODO: } } } Note that it's a very specific circumstance. You have to be running the code in a tight loop to exercise the buggy JIT optimization. Note also that because this is a JIT bug, you have to compile the code and run it from the command line. Optimization is automatically disabled for programs launched from the Visual Studio IDE, even in release mode. Also remember that you need the .NET Framework 2.0 installed to exercise this. So the bug is in the optimizer itself - potentially serious, I guess. I've not heard of anybody actually being affected by this in a production app though.
Huh. I use isnullorempty in hundreds maybe thousands of places in one app, but I can't think of any tight loops it would be in and I've never seen a mysterious error related to it and we have thousands of users of our software world wide and would hear about any errors pretty quickly. I guess it's a non issue for most people, but I still find it wierd there's no official Microsoft bug report / issue number for it.
"110%" - it's the new 70%