.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

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

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

[weilawei]

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