.NET 4.6 Optimizer Bug Causes Methods To Get Wrong Parameters

tobiasly writes: A serious bug in the just-released .NET 4.6 runtime causes the JIT compiler to generate incorrectly-optimized code which results in methods getting called with different parameters than what were passed in. Nick Craver of Stack Exchange has an excellent write-up of the technical details and temporary workarounds; Microsoft has acknowledged the problem and submitted an as-yet unreleased patch.

This problem is compounded by Microsoft's policy of replacing the existing .NET runtime, as opposed to the side-by-side runtimes which were possible until .NET 2.0. This means that even if your project targets .NET 4.5, it will get the 4.6 runtime if it was installed on that machine. Since it's not possible to install the just-released Visual Studio 2015 without .NET 4.6, this means developers must make the difficult choice between using the latest tools or risking crippling bugs such as this one.

Comments

Re:unless you need it wait...

[gstoddart]

Which is the problem with Microsoft trying to force people to use it, and deciding they're going to be forcing updates.

They're saying they're doing it for security, but time and time again Microsoft has demonstrated they're not trustworthy in their updates.

My experience says taking a day 1 anything from Microsoft is a recipe for disaster. In fact, taking a day 1 from anybody is.

Microsoft is basically breaking first and fixing later. The problem is it isn't Microsoft's stuff which ends up broken, and bad release engineering is costly to companies.

Sorry, but Microsoft hasn't demonstrated we should ever trust them with continuous releases. They've demonstrated the opposite, in fact.

Re:Who cares?

[gstoddart]

Why is the story of Slashdot being sold not on SLASHDOT!?!?!?

Well, ignoring the rest of your comment, this is actually worth highlighting.

The Company acquired Slashdot Media in 2012 both to provide the Dice business with broader reach into Slashdot's user community base and to extend the Dice business outside North America by engaging with SourceForge's significant international technology user community. The Company, however, has not successfully leveraged the Slashdot user base to further Dice's digital recruitment business; and with the acquisition of The IT Job Board and success of Open Web, the anticipated value to the Company of the SourceForge traffic outside North America has not materialized. The Company now plans to divest the business, as it does not fit within the Company's strategic initiatives and believes the Slashdot Media business will have the opportunity to improve its financial performance under different ownership.

Good riddance, dice.

Sorry we couldn't help you leverage your synergies.

Actually, we're not sorry at all.

The bigger issue

[RingDev]

This bug is in the JIT optimizer of the 4.6 framework. For apps you are developing, it's absolutely no problem, you just go into the compiler settings and uncheck the 'optimize' setting.

The problem though, is that the 4.6 framework is an in-place replacement for the 4.5 framework, which was an in-place replacement for the 4.0 framework. And the JIT optimizer is on by default. So if you install the 4.6 framework, it could potentially introduce this bug into any application developed targeting the 4.0, 4.5, or 4.6 framework that is already distributed.

Luckily, it appears as though the issue is a combination of a nullable int that has a bug in the boxing/unboxing of it's operator when calling the .hasValue method. So the actual number of places where this will actually pop up is hopefully quite limited.

That said, MS better get this patch deployed ASAP. Or if you are in a critical hurry, the correction has already been committed to the .Net Git repo, so you can brave a build from that.

-Rick

Re:Change Is Life

[Ravaldy]

So much for a new 'improved' version

I don't know if you were being negative or playful when you wrote this but with all major overhauls there's going to be bugs. You just need to give them a little bit of time to work out the quirks they didn't catch during internal QC. Correct me if I'm wrong but I don't believe this was ever a public BETA.

I only installed VS2013 a few months ago after it reached SP4

I used VS2005 6 months after. It was perfectly fine. VS2010 was a welcomed upgrade that encountered minor issues along the way that were resolved with the patches released not that much later. I didn't force a 2013 upgrade for our dev team but I did trial it on a VM. VS2013 had noticeable issues at launch but that appeared all solved by the 30 day mark. We decided to wait for VS2015 because 2010 was fine and we didn't find 2013 had enough to offer in terms of improvement for our dev team.

The good news is that it was caught and will be fixed quickly by the sound of it.

Re:The joys of youth

[ADRA]

I've included some notes from my own experience to help those (not necessarily parent poster) avoid similar failures.

- don't get locked in to single-vendor technology that might disappear on a moment's notice.
Realistically, evaluate if said technologies can survive company collapse or not. Languages / Technologies with heavy internal investment like C# are a lot more coupled to their companies than say PHP, Ruby, etc. That said, maybe the Mono/Apache/etc.. type groups out there could keep the lang alive if MS pulled the rug. Java could be better off if Oracle killed it to open up the ecosystem pieces they've kept ransom. HTML/Javascript are completely open (though standards keep things semi-coherent) but realistically 3-4 vendors control the narrative and if 2 decided to go in a different direction, you'll have a lot of chaos to keep things working.

- hide API's inside your own classes. That makes ripping them out and replacing them with something else so much easier.
Well, the general mantra of layering access to things certainly mitigates unnecessary coupling which is a good thing. This should be applied everywhere though, not just inner class scoping.

- stick to standards.
Yep, and invent some of your own if there's a lack of good standardization where there should be.

- invest in regular modernisation. Do it when reasonably can, not when you absolutely must.
A tricky proposition, but one that should certainly be striven for. Admittedly, saying lets drop all this stuff that produces more revenue to work on X which may eventually help us maximize revenue in the future is certainly not as clear cut, but in the ideal world, the code is always getting improved, polished, simplified, etc.. Writing (CS101 here) low coupled, high cohesion code will vastly simplify future improvements. Just make sure that you always consider 3rd party libraries / platform libraries / language quirks included into external dependencies that may evolve over time.

- refactor whatever stinks.
Whenever I try refacting crap (core piece of functionality), I write a TON of extra tests for before/after comparison because no matter how perfect your re-implementation, there will always be those bazaar corner cases that worked (possibly through fluke/magic) in the original spahgetti that violates the implied or explicit contracts in the future. Refactor for sure, but don't ripshod, or your eventual replacement will be refacting/fixing your POC for much the same reason you refactored.

- keep your own skills up to date. Apply as needed.
This is never bad advice, but just remember that just because you learn a new technique / technology, don't go running out to refactor everything to use it. Generally if it was popular 10-15 years ago, its probably stood the test of time and passed, while newer tech should be looked at carefully and evaluated for specific cases where appropriate.