Nick Craver 與 Marc Gravell 在 .NET 4.6 中引入的 RyuJIT 編譯器中發(fā)現(xiàn)了一個嚴重的 bug，.NET 4.6 會隨著 Visual Studio 2015 一起安裝，并且也預(yù)裝在 Windows 10 操作系統(tǒng)中。Craver 和 Gravell 已經(jīng)提交了這個 bug 的詳細說明，他們追蹤到問題的根源來自于 RyuJIT 在處理尾調(diào)用優(yōu)化時的一個問題。這個問題產(chǎn)生的結(jié)果是“……我們所調(diào)用的方法沒有獲得所傳入的參數(shù)”，正如他們所說，如果受到此問題影響的變量原本是用于處理重要的值，那么將因此造成嚴重的后果。
　　來自微軟的 Matt Mitchell 對這個發(fā)現(xiàn)做出了回應(yīng)，他提交了一個補?。ㄍㄟ^ pull request）以修復(fù)這個問題。有趣的是，有人發(fā)現(xiàn)這個問題本來已經(jīng)被修復(fù)了，但在三天前（7 月 24 日）又被微軟的另一位開發(fā)者撤消了。Craver 指出，這個 bug 的存在之所以不那么容易立即發(fā)現(xiàn)，是由于以下幾點原因：
　　這個問題只有在應(yīng)用了代碼優(yōu)化之后才會出現(xiàn)，由于多數(shù)開發(fā)者與項目都是在 DEBUG 模式開發(fā)的，因此在本地環(huán)境中看不出來。
　　這也意味著你只能在 RELEASE 模式下發(fā)現(xiàn)它，對于多數(shù)人來說，這就意味著它只存在于生產(chǎn)環(huán)境。
　　一旦為進程附加了調(diào)試器就會改變它的行為，這幾乎讓這個問題完全隱形了。
　　如果在代碼中加入一句 Debug.WriteLine ()，就很可能修復(fù)這個問題，因為尾調(diào)用的方式產(chǎn)生了變化。
　　有一個重要的提示：即使微軟已經(jīng)在 GitHub 代碼庫中接受了這個補丁，也不意味著這個問題就此結(jié)束了。對于已經(jīng)安裝了 .NET 4.6 的用戶來說，微軟必須為他們提供新的二進制包。Craver 建議，如果開發(fā)者還沒有在生產(chǎn)環(huán)境上部署 .NET 4.6，那么請耐心等待打了補丁的安裝包出現(xiàn)。而如果你已經(jīng)安裝了 .NET 4.6（無論在哪一種環(huán)境中），Craver 建議你立即關(guān)閉 RyuJIT，并且通過一些概念驗證式的代碼告訴開發(fā)者如何進行操作。另外還有一個重要的提示，由于這個問題所影響的是 RyuJIT 編譯器，因此它同樣會影響那些目標為較早版本的 .NET 運行時。
　　微軟的回應(yīng)（更新于 2015 年 7 月 28 日）
　　來自微軟的 Rich Lander 對于 Craver 與 Gravell 的報告進行了正式的回應(yīng)，他在回應(yīng)中提到這個 bug 僅會影響 64 位進程，而不會影響 32 位進程。雖然 Lander 表示他的團隊目前并不認為這個問題會被人利用，但他們還是會將修復(fù)代碼提交至發(fā)布流程中。
　　在 Lander 的說明中，他也推薦在使用 .NET Framework 4.6 的環(huán)境中關(guān)閉 RyuJIT 的方式，直到補丁包出現(xiàn)為止。不過，考慮到故障檢測不等人，最好還是先研究一下這個 bug 是否確實對你的實際情況生產(chǎn)了影響，因為如果你的應(yīng)用程序有什么異常的行為，也有可能是別的原因引起的。
　　根據(jù) Lander 的說明，F(xiàn)#的開發(fā)者最有可能遇到由這個 bug 所引起的問題，因此應(yīng)當(dāng)盡量避免安裝 .NET 4.6，Lander 在文中給出了如何重現(xiàn)這個問題的 C# 與F#示例代碼。微軟目前還沒有說明這個補丁的發(fā)布日期。