Posts about Bugs
65535 interfaces ought to be enough for anybody
It was a bright, sunny morning. There were no signs of trouble. I came to work, opened Slack, and received many messages from my coworkers about failed tests.
After a few hours of investigation, the situation became clear:
- I'm responsible for the unit tests subsystem in Rider, and only tests from this subsystem were failing.
- I didn't commit anything to the subsystem for a week because I worked with a local branch. Other developers also didn't touch this code.
- The unit tests subsystem is completely independent. It's hard to imagine a situation when only the corresponded tests would fail, thousands of other tests pass, and there are no changes in the source code.
git blamehelped to find the "bad commit": it didn't include anything suspicious, only a few additional classes in other subsystems.- Only tests on Linux and MacOS were red. On Windows, everything was ok.
- Stacktraces in failed tests were completely random. We had a new stack trace in each test from different subsystems. There was no connection between these stack traces, unit tests source code, and the changes in the "bad commit." There was no clue where we should look for a problem.
So, what was special about this "bad commit"? Spoiler: after these changes, we sometimes have more than 65535 interface implementations at runtime.
Read moreA bug story about named mutex on Mono
When you write some multithreading magic on .NET, you can use a cool synchronization primitive called Mutex:
var mutex = new Mutex(false, "Global\\MyNamedMutex");
You also can make it named (and share the mutex between processes) which works perfectly on Windows:
However, today the .NET Framework is cross-platform, so this code should work on any operation system. What will happen if you use named mutex on Linux or MacOS with the help of Mono or CoreCLR? Is it possible to create some tricky bug based on this case? Of course, it does. Today I want to tell you a story about such bug in Rider which was a headache for several weeks.
Read moreInvalidDataException in Process.GetProcesses
Consider the following program:
public static void Main(string[] args)
{
try
{
Process.GetProcesses();
}
catch (Exception e)
{
Console.WriteLine(e);
}
}
It seems that all exceptions should be caught.
However, sometimes, I had the following exception on Linux with dotnet cli-1.0.0-preview2:
$ dotnet run
System.IO.InvalidDataException: Found invalid data while decoding.
at System.IO.StringParser.ParseNextChar()
at Interop.procfs.TryParseStatFile(String statFilePath, ParsedStat& result, ReusableTextReader reusableReader)
at System.Diagnostics.ProcessManager.CreateProcessInfo(ParsedStat procFsStat, ReusableTextReader reusableReader)
at System.Diagnostics.ProcessManager.CreateProcessInfo(Int32 pid, ReusableTextReader reusableReader)
at System.Diagnostics.ProcessManager.GetProcessInfos(String machineName)
at System.Diagnostics.Process.GetProcesses(String machineName)
at System.Diagnostics.Process.GetProcesses()
at DotNetCoreConsoleApplication.Program.Main(String[] args) in /home/akinshin/Program.cs:line 12
How is that possible?
Read moreNuGet2 and a DirectorySeparatorChar bug
In Rider, we care a lot about performance. I like to improve the application responsiveness and do interesting optimizations all the time. Rider is already well-optimized, and it's often hard to make significant performance improvements, so usually I do micro-optimizations which do not have a very big impact on the whole application. However, sometimes it's possible to improve the speed of a feature 100 times with just a few lines of code.
Rider is based on ReSharper, so we have a lot of cool features out of the box. One of these features is Solution-Wide Analysis which lets you constantly keep track of issues in your solution. Sometimes, solution-wide analysis takes a lot of time to run because there are many files which should be analyzed. Of course, it works super fast on small and projects.
Let's talk about a performance bug (#RIDER-3742) that we recently had.
- Repro: Open Rider, create a new "ASP .NET MVC Application", enable solution wide-analysis.
- Expected: The analysis should take 1 second.
- Actual: The analysis takes 1 second on Windows and 2 minutes on Linux and MacOS.
Unrolling of small loops in different JIT versions
Challenge of the day: what will the following code display?
struct Point
{
public int X;
public int Y;
}
static void Print(Point p)
{
Console.WriteLine(p.X + " " + p.Y);
}
static void Main()
{
var p = new Point();
for (p.X = 0; p.X < 2; p.X++)
Print(p);
}
The right answer: it depends. There is a bug in CLR2 JIT-x86 which spoil this wonderful program. This story is about optimization that called unrolling of small loops. This is a very interesting theme, let's discuss it in detail.
Read moreA bug story about JIT-x64
Can you say, what will the following code display for step=1?
public void Foo(int step)
{
for (int i = 0; i < step; i++)
{
bar = i + 10;
for (int j = 0; j < 2 * step; j += step)
Console.WriteLine(j + 10);
}
}
If you think about specific numbers, you are wrong. The right answer: it depends. The post title suggests to us, the program can has a strange behavior for x64.
Read moreHappy Monday!
Today I tell you a story about one tricky bug. The bug is a tricky one because it doesn't allow me to debug my application on Mondays. I'm serious right now: the debug mode doesn't work every Monday. Furthermore, the bug literally tell me: "Happy Monday!".
So, the story. It was a wonderful Sunday evening, no signs of trouble. We planned to release a new version of our software (a minor one, but it includes some useful features). Midnight on the clock. Suddenly, I came up with the idea that we have a minor bug that should be fixed. It requires a few lines of code and 10 minutes to do it. And I decided to write needed logic before I go to sleep. I open VisualStudio, lunch build, and wait. But something goes wrong, because I get the following error:
Error connecting to the pipe server.
Hmm. It is a strange error.
Read more