.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

[Virtucon]

I wish it would go back to allowing side by side operation of .NET instead of replacing 4.5.X with 4.6. I have Win 10 isolated in VMs and 4.6 is already breaking quite a few things. Nicks got a good workaround for this particular problem but I still can't believe that something this basic missed QA in MSFT because .NET regression tests would be a basic must have including JIT problems.

Re:The joys of youth

[Trailer Trash]

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.

Yeah, easy to say. When I was programming Microsoft systems (admittedly 20 years ago) the problem was that you were faced with the choice of upgrading and risking crap like this or not upgrading and dealing with problems that Microsoft would only fix "in the next upgrade".

So glad I left that behind.

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

[netsavior]

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.

This mindset is why I still have to support companies that refuse to migrate from IE8. Thanks.

There are currently 2 common mindsets.

1) find a stable version and prevent yourself from ever getting anything better and any upgrade is sure to break tons of stuff
or
2) upgrade versions every time a new one comes out so you get the benefits of incremental improvements, sure stuff breaks, but the next patch will fix it in a matter of days/weeks

On April 8th 2014 the joyful day of XP/IE6 death, which should be considered an international holiday, I think a lot of companies realized that the days of use a "Stable version" for decades is over/no longer realistic.

Now I am not saying "just start upgrading everything always" because the worst thing you can do is try to step out in front of the subway car of continuous integration/continuous improvement after letting a project mature on "stick with the stable version" mentality; but I am saying... the half-assed "stable version" meets patch tuesday bullshit that microsoft is doing will continue to bite you and everybody else in the ass until that entire tech stack stops doing that crap and starts doing the continuous integration thing for real. Chrome does it, every app on your phone tries to do it, "cloud" products do it (that is one of the reasons execs love "cloud").

Microsoft might as well be mailing floppies for how broken and relevant their process is.

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.

Re: The joys of youth

[MemeRot]

Only 4.5.2 and one flavor of 3.x (and of course 4.6) will be supported come January. Makes me wish nuget had an option to only pull packages for supported frameworks, I think that's all on the package maintainer today

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

[Joce640k]

Wait for at least SP1. Let others be the beta testers.

Re:Change Is Life

[gstoddart]

You know, if Microsoft changes the library in place and breaks it ... I don't blame professional developers at all.

I blame whatever idiot at Microsoft was responsible for not fucking breaking existing stuff.

This is just lousy QA.

I feel bad for anybody who is going to be the victim of Micrtosoft's idiotic policy of deciding it's their computer and they'll update it as they see fit. Because it is a certainty Microsoft will break a large amount of computers and leave that to be the problem of the people who own it.

And, I'm sorry, but if Microsoft is going to force updates and break machines, they should be charged under the computer fraud and abuse act, or whatever it is.

Because this is pretty much damaging other people's property, and shouldn't be legal just because some asshole at Microsoft updated an EULA which says they're allowed to do this.

Re:Change Is Life

[Joce640k]

I installed VS2015 on a spare machine for a laugh - I actually managed to get them to fix an ancient VS bug fixed by nagging them enough. The fix was in VS2015 and I wanted to see it with my own eyes.

It crashed and burned about once a minute for the entire time I tried it, no chance to save any work. So much for a new 'improved' version.

I only installed VS2013 a few months ago after it reached SP4. I'm not expecting VS2015 to be usable any time soon (I _would_ like to have my bug fixed though because it happens constantly...OTOH it's been bothering me since VC++ 6.0 so I'm almost used to it by now)

Re:Change Is Life

[tompaulco]

The folks I feel sorry for are the students - Win 10 is released Friday, all the new computers being bought for Fall term starting will have it, students taking programming courses will often be stuck with the newest of the new since the instructor adopted (or wrote) the latest text book,

That certainly wasn't the case when I was in school. They were years behind on versions of programming languages. As for IDEs, there weren't any in use. I used vi for my programming assignments. Borland C++ was available, but only on Windows, and the University mostly had Sun and SGI workstations.
On the whole, though, I think it worked out better, because I got an understanding of working with libraries and linking that would enable me to understand how to get something to work if it didn't work automatically in an IDE.

Re:Change Is Life

[tompaulco]

I might be flamed for saying this, but if you can't be a software developer without "community support" like asking questions on StackOverflow, then you're not really a software developer. (Likewise, if a tool can't be used without asking questions on stackoverflow, it's the wrong tool to be using for anything serious).

I have yet to ask a question on stackoverflow, but I refer to it a lot when dealing with third party tools and libraries. The reason being that documentation is usually extremely weak. You can usually find a reference to the methods, but to understand when you might want to use one or another is not really explained. it is helpful to find an example of someone who has used it. Then, you have to figure out what the latest hipster way to instantiate an object is since apparently constructors aren't cool anymore, and the best practice for instancing changes from week to week and the documentation is sometimes not updated to reflect that, it just has a constructor. Of course, examples are always point in time, and nobody ever goes back to edit those, so a lot of the time, you at least get deprecated warnings in example code, if not just outright failure because methods have gone away or signatures changed.
In other words, the same community that complains about MS constantly fixing what ain't broke, is constantly fixing what ain't broke.

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

[SuperKendall]

It's not all that hard to stick with a toolkit version for a couple of months (or to be honest, even a project lasting up to 18 months is no big deal.

That depends on the system. If you are doing iOS development, while 18 months is possible it's not advisable due to every new version of XCode (one major, a few minor updates every year) having more advanced tooling, compilers, frameworks... furthermore you are going to have to use a beta version at some point to test and debug your software on for un-released versions of iOS that you have to make sure you work well on before they are released.

I see your point, I was more speaking to the attitude of people that want to spend years without upgrading the underlying technologies involved in building and running your project... the longer you wait the worse the transition is, and like I said in the meantime you are also missing out on things that could have made development easier or resolved bugs you had to fix.

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.

Re:Who cares?

[0123456]

I guess the expected tsunami of techies eager for SJW articles never arrived.

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.

Re:unless you need it wait...

[gstoddart]

Oh, don't misunderstand me ... I know people do need this stuff when it's fresh and steaming, and have no choice.

I'm saying that, in general, as a change management strategy, taking the first day release of a fix has been demonstrated to be a terrible idea. Over and over and over by pretty much every software vendor.

Many of us support production machines and mission critical things, which means there's no way in hell we'd apply these on the day they get released.

What really annoys me is Microsoft's increasing push to force people to take those updates on day one, and be stuck with the consequences of that.

So, imagine a world in which some poor schmuck is running the version of Windows 10 which doesn't let you defer updates. When Microsoft pushes this crap out, suddenly a huge amount of people have broken systems. Microsoft isn't going to pay to fix that. Microsoft isn't going to have to deal with the consequences of the outage.

So, the general advice of "if you don't absolutely need this on the day of release, wait" is the best strategy if you can't be on the bleeding edge every day Microsoft has a new fix.

Microsoft seems bent on taking that away. And that, in my opinion, is idiotic and dangerous.

If you need to be on the cutting edge, you should probably be taking your own steps to recover from that. Mine is let everyone else test first. ;-)