.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

The joys of youth

[weilawei]

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.

If you're a dev, you shouldn't be chasing versions. Find a stable version, stick with it through your project. SE already has enough of that "stuff changing out from under me" feel without adding to the issue.

Re:The joys of youth

[johannesg]

Your advice means I would be stuck using Visual Studio 5, and GCC 2.8.0. Hope you don't mind me 'chasing versions'...

I have, however, refrained from chasing every Microsoft fad over the years, meaning I'm now in charge of a modern C++11 application, happily running on Linux and Windows, in 32-bit and 64-bit mode, and with full support for things like unicode and IPv6. Instead of hoping that Microsoft would get off their lazy ass and finally update MFC, or something...

There was a question here on slashdot on how to plan for 20 year development cycles the other day. I'm almost at that point now, and let me tell you what keeps an application alive:

- don't get locked in to single-vendor technology that might disappear on a moment's notice.
- hide API's inside your own classes. That makes ripping them out and replacing them with something else so much easier.
- stick to standards.
- invest in regular modernisation. Do it when reasonably can, not when you absolutely must.
- refactor whatever stinks.
- keep your own skills up to date. Apply as needed.

Just my two cents, of course...

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.

Change Is Life

[SuperKendall]

On the other hand if you fall behind current dev tools, you miss out on the potential for a lot of community support, risk being crippled by the bugs that remain in the older system that are fixed the new, and hamstring your ability to work as effectively as you might because you cannot use newer tooling/frameworks to help with development...

Yes SE has a lot of stuff changing, it always has and always will. But cringing from the pain will not help, SE is not finding any kind of safe plateau (because there are none). It is moving ever forward at a reasonable pace, using nettles as handholds where you must grasp them firmly as you ascend, living with the brief pain to move forward.

Re:Change Is Life

[weilawei]

You don't need to stick to it forever, just long enough for it to become stable and reasonably well accepted. You don't need to be the early adopter in the middle of active development. When you've got some breathing room (your stuff is relatively stable) and aren't going to waste a weeks worth of your team's money, then you can think about moving to newer versions of tools, libraries, etc..

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:Change Is Life

[Ravaldy]

Why are you always ranting about MS? You know you don't have to use their products right?

You know that software bugs are part of every eco system right? Linux, MAC and MS have them. Many of them come in the form of bad firmware or bad drivers that can actually ruing hardware.

Should we all go after Seagate for putting out millions of drives with defective firmware that eventually self terminates the hard drive? I think that's far more destructive than this .NET bug which can be fixed with a simple update (one that will be posted shortly I'm sure).

Should we start talking about the heart bleed security flaw? I think a defective OS library is far less damaging to a person than their identify being stolen due to a bug in a security protocol.

If you hate MS that much stop using/buying their products because you clearly can't handle them. If you don't have MS products then just shut up or get a bias opinion that we can actually respect instead of this childish ranting.

Re:Who cares?

[iONiUM]

Lots of people care, including myself. I develop using .NET and this is very useful information for me. This is the exact kind of information I would expect out of Slashdot: tech information that helps me in my tech-oriented job.

.NET is in no way "dead", despite your obvious hatred for it.

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:Who cares?

[weilawei]

I check the Disable Advertising box. Therefore, in order to contribute ad impressions, I must start flame wars.