String.IsNullOrEmptyOr... NullRefererenceException!
-
: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:
-
: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:
That warrants for a major WTF:omg::wtf:
-
: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:
-
: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:
My first thought: "poor Raymond". that it only occurs when a program is compiler in release mode and run outside of the development environment on a PC with .NET 2.0 installed. Workaround: ask your customer to install C# express, and run your project from there :rolleyes: (It's free after all) http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=113102[^] wrote: Although this is a bug in the JIT, a simple workaround exists. We don't pre-emptively make it a QFE though. Well - it's not THAT important...
it's a major WTF indeed, and we DO NEED a fix for clients running .NET 2.0 applications.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
: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:
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
-
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:
The Connect site is for reporting problems in the current or beta/CTP versions that you don't need an immediate fix for
Which is the major public face problem for the connect site. It leaves people with "you are hoised, but until you upgrade we don't care".
Mike Dimmick wrote:
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.
That's the other problem wih MS support...
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!|FoldWithUs! | sighist -
: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 have nothing but idiocy from MS Connect (is it outsourced?). I submitted a problem (insane memory allocation due to string concatenation in what appears to be a wrongfully placed trace/debug statement) with wsdl. The problem occurs (and can be seen) when running on a large (300+ in my case) number of webservice endpoints. You know the 1st reply I got? Not reproducible, guess what the tester did? He tested it on 1 (yes one, uno) endpoint. DUH!
**
xacc.ide-0.2.0.75 - now with C# 3.5 support and Navigation Bar!
**
-
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%