skip to content
Relatively General .NET

There is no self-closing tag in html

by Gérald Barré

posted on: April 14, 2025

There is no self-closing tag in html! This statement seems wrong as you may have seen self-closing tags in html, such as <img src="foo.jpg" /> (with /> at the end). However, this is not a concept in html. Let me explain.While HTML looks similar to a permissive XML, it's not XML. As an exam

Pricing transparency in RavenDB Cloud

by Oren Eini

posted on: April 11, 2025

Cloud service costs can often be confusing and unpredictable.RavenDB Cloud's new feature addresses this by providing real-time cost predictions whenever you make changes to your system. This transparency allows you to make informed choices about your cluster and easily incorporate cost considerations into your decision loop to take control of your cloud budget.. The implementation of cost transparency and visibility features within RavenDB Cloud has an outsized impact on cost management and FinOps practices. It empowers you to make informed decisions, optimize spending, and achieve better financial control.The idea is to make it easier for you to spend your money wisely. I’m really happy with this feature. It may seem small, but it will make a difference. It also fits very well with our overall philosophy that we should take the burden of complexity off your shoulders and onto ours.

.NET 10 Preview 3 is now available!

by .NET Team

posted on: April 10, 2025

Find out about the new features in .NET 10 Preview 3 across the .NET runtime, SDK, libraries, ASP.NET Core, Blazor, C#, .NET MAUI, and more!

When racing the Heisenbug, code quality goes out the Windows

by Oren Eini

posted on: April 09, 2025

There are at least 3 puns in the title of this blog post. I’m sorry, but I’m writing this after several days of tracking an impossible bug. I’m actually writing a set of posts to wind down from this hunt, so you’ll have to suffer through my more prosaic prose. This bug is the kind that leaves you questioning your sanity after days of pursuit, the kind that I’m sure I’ll look back on and blame for any future grey hair I have. I’m going to have another post talking about the bug since it is such a doozy. In this post, I want to talk about the general approach I take when dealing with something like this.Beware, this process involves a lot of hair-pulling. I’m saving that for when the real nasties show up.The bug in question was a race condition that defied easy reproduction. It didn’t show up consistently—sometimes it surfaced, sometimes it didn’t. The only “reliable” way to catch it was by running a full test suite, which took anywhere from 8 to 12 minutes per run. If the suite hung, we knew we had a hit. But that left us with a narrow window to investigate before the test timed out or crashed entirely. To make matters worse, the bug was in new C code called from a .NET application.New C code is a scary concept. New C code that does multithreading is an even scarier concept. Race conditions there are almost expected, right? That means that the feedback cycle is long. Any attempt we make to fix it is going to be unreliable - “Did I fix it, or it just didn’t happen?” and there isn’t a lot of information going on.The first challenge was figuring out how to detect the bug reliably. Using Visual Studio as the debugger was useless here—it only reproduced in release mode, and even with native debugging enabled, Visual Studio wouldn’t show the unmanaged code properly. That left us blind to the C library where the bug resided. I’m fairly certain that there are ways around that, but I was more interested in actually getting things done than fighting the debugger. We got a lot of experience with WinDbg, a low-level debugger and a real powerhouse. It is also about as friendly as a monkey with a sore tooth and an alcohol addiction. The initial process was all about trying to reproduce the hang and then attach WinDbg to it.Turns out that we never actually generated PDBs for the C library. So we had to figure out how to generate them, then how to carry them all the way from the build to the NuGet package to the deployment for testing - to maybe reproduce the bug again. Then we could see in what area of the code we are even in.Getting WinDbg attached is just the start; we need to sift through the hundreds of threads running in the system. That is where we actually started applying the proper process for this.This piece of code is stupidly simple, but it is sufficient to reduce “what thread should I be looking at” from 1 - 2 minutes to 5 seconds. SetThreadDescription(GetCurrentThread(), L"Rvn.Ring.Wrkr");I had the thread that was hanging, and I could start inspecting its state. This was a complex piece of code, so I had no idea what was going on or what the cause was. This is when we pulled the next tool from our toolbox.void alert() { while (1) { Beep(800, 200); Sleep(200); } }This isn’t a joke, it is a super important aspect. In WinDbg, we noticed some signs in the data that the code was working on, indicating that something wasn’t right. It didn’t make any sort of sense, but it was there. Here is an example:enum state { red, yellow, green }; enum state _currentState;And when we look at it in the debugger, we get:0:000> dt _currentState Local var @ 0x50b431f614 Type state 17 ( banana_split )That is beyond a bug, that is some truly invalid scenario. But that also meant that I could act on it. I started adding things like this:if(_currentState != red && _currentState != yellow && _currentState != green) { alert(); }The end result of this is that instead of having to wait & guess, I would now:Be immediately notified when the issue happened.Inspect the problematic state earlier.Hopefully glean some additional insight so I can add more of those things. With this in place, we iterated. Each time we spotted a new behavior hinting at the bug’s imminent trigger, we put another call to the alert function to catch it earlier. It was crude but effective—progressively tightening the noose around the problem.Race conditions are annoyingly sensitive; any change to the system—like adding debug code—alters its behavior. We hit this hard. For example, we’d set a breakpoint in WinDbg, and the alert function would trigger as expected. The system would beep, we’d break in, and start inspecting the state. But because this was an optimized release build, the debugging experience was a mess. Variables were often optimized away into registers or were outright missing, leaving us to guess what was happening.I resorted to outright hacks like this function:__declspec(noinline) void spill(void* ptr) { volatile void* dummy = ptr; dummy; // Ensure dummy isn't flagged as unused }The purpose of this function is to force the compiler to assign an address to a value. Consider the following code:if (work->completed != 0) { printf("old_global_state : %p, current state: %p\n", old_global_state, handle_ptr->global_state); alert(); spill(&work); }Because we are sending a pointer to the work value to the spill function, the compiler cannot just put that in a register and must place it on the stack. That means that it is much easier to inspect it, of course.Unfortunately, adding those spill calls led to the problem being “fixed”, we could no longer reproduce it. Far more annoyingly, any time that we added any sort of additional code to try to narrow down where this was happening, we had a good chance of either moving the behavior somewhere completely different or masking it completely.Here are some of our efforts to narrow it down, if you want to see what the gory details look like.At this stage, the process became a grind. We’d hypothesize about the bug’s root cause, tweak the code, and test again. Each change risked shifting the race condition’s timing, so we’d often see the bug vanish, only to reappear later in a slightly different form. The code quality suffered—spaghetti logic crept in as we layered hacks on top of hacks. But when you’re chasing a bug like this, clean code takes a back seat to results. The goal is to understand the failure, not to win a style award.Bug hunting at this level is less about elegance and more about pragmatism. As the elusiveness of the bug increases, so does code quality and any other structured approach to your project. The only thing on your mind is, how do I narrow it down?. How do I get this chase to end? Next time, I’ll dig into the specifics of this particular bug. For now, this is the high-level process: detect, iterate, hack, and repeat. No fluff—just the reality of the chase. The key in any of those bugs that we looked at is to keep narrowing the reproduction to something that you can get in a reasonable amount of time. Once that happens, when you can hit F5 and get results, this is when you can start actually figuring out what is going on.

Production postmortem

by Oren Eini

posted on: April 07, 2025

This post isn’t actually about a production issue—thankfully, we caught this one during testing. It’s part of a series of blog posts that are probably some of my favorite posts to write. Why? Because when I’m writing one, it means I’ve managed to pin down and solve a nasty problem. This time, it’s a race condition in RavenDB that took mountains of effort, multiple engineers, and a lot of frustration to resolve. For the last year or so, I’ve been focused on speeding up RavenDB’s core performance, particularly its IO handling. You might have seen my earlier posts about this effort. One key change we made was switching RavenDB’s IO operations to use IO Ring, a new API designed for high-performance, asynchronous IO, and other goodies. If you’re in the database world and care about squeezing every ounce of performance out of your system, this is the kind of thing that you want to use.This wasn’t a small tweak. The pull request for this work exceeded 12,000 lines of code—over a hundred commits—and likely a lot more code when you count all the churn. Sadly, this is one of those changes where we can’t just split the work into digestible pieces. Even now, we still have some significant additional work remaining to do. We had two or three of our best engineers dedicated to it, running benchmarks, tweaking, and testing over the past few months. The goal is simple: make RavenDB faster by any means necessary. And we succeeded, by a lot (and yes, more on that in a separate post). But speed isn’t enough; it has to be correct too. That’s where things got messy.Tests That Hang, SometimesWe noticed that our test suite would occasionally hang with the new code. Big changes like this—ones that touch core system components and take months to implement—often break things. That’s expected, and it’s why we have tests. But these weren’t just failures; sometimes the tests would hang, crash, or exhibit other bizarre behavior. Intermittent issues are the worst. They scream “race condition,” and race conditions are notoriously hard to track down.Here’s the setup. IO Ring isn’t available in managed code, so we had to write native C code to integrate it. RavenDB already has a Platform Abstraction Layer (PAL) to handle differences between Windows, Linux, and macOS, so we had a natural place to slot this in. The IO Ring code had to be multithreaded and thread-safe. I’ve been writing system-level code for over 20 years, and I still get uneasy about writing new multithreaded C code. It’s a minefield. But the performance we could get… so we pushed forward… and now we had to see where that led us.Of course, there was a race condition. The actual implementation was under 400 lines of C code—deliberately simple, stupidly obvious, and easy to review. The goal was to minimize complexity: handle queuing, dispatch data, and get out. I wanted something I could look at and say, “Yes, this is correct.” I absolutely thought that I had it covered.We ran the test suite repeatedly. Sometimes it passed; sometimes it hung; rarely, it would crash.When we looked into it, we were usually stuck on submitting work to the IO Ring. Somehow, we ended up in a state where we pushed data in and never got called back. Here is what this looked like. 0:019> k # Call Site 00 ntdll!ZwSubmitIoRing 01 KERNELBASE!ioring_impl::um_io_ring::Submit+0x73 02 KERNELBASE!SubmitIoRing+0x3b 03 librvnpal!do_ring_work+0x16c 04 KERNEL32!BaseThreadInitThunk+0x17 05 ntdll!RtlUserThreadStart+0x2cIn the previous code sample, we just get the work and mark it as done. Now, here is the other side, where we submit the work to the worker thread.int32_t rvn_write_io_ring(void* handle, int32_t count, int32_t* detailed_error_code) { int32_t rc = 0; struct handle* handle_ptr = handle; EnterCriticalSection(&handle_ptr->global_state->lock); ResetEvent(handle_ptr->global_state->notify); char* buf = handle_ptr->global_state->arena; struct workitem* prev = NULL; for (int32_t curIdx = 0; curIdx < count; curIdx++) { struct workitem* work = (struct workitem*)buf; buf += sizeof(struct workitem); *work = (struct workitem){ .prev = prev, .notify = handle_ptr->global_state->notify, }; prev = work; queue_work(work); } SetEvent(IoRing.event); bool all_done = false; while (!all_done) { all_done = true; WaitForSingleObject(handle_ptr->global_state->notify, INFINITE) ResetEvent(handle_ptr->global_state->notify); struct workitem* work = prev; while (work) { all_done &= InterlockedCompareExchange( &work->completed, 0, 0); work = work->prev; } } LeaveCriticalSection(&handle_ptr->global_state->lock); return rc; }We basically take each page we were asked to write and send it to the worker thread for processing, then we wait for the worker to mark all the requests as completed. Note that we play a nice game with the prev and next pointers. The next pointer is used by the worker thread while the prev pointer is used by the submitter thread.You can also see that this is being protected by a critical section (a lock) and that there are clear hand-off segments. Either I own the memory, or I explicitly give it to the background thread and wait until the background thread tells me it is done. There is no place for memory corruption. And yet, we could clearly get it to fail.Being able to have a small reproduction meant that we could start making changes and see whether it affected the outcome. With nothing else to look at, we checked this function:void queue_work_origin(struct workitem* work) { work->next = IoRing.head; while (true) { struct workitem* cur_head = InterlockedCompareExchangePointer( &IoRing.head, work, work->next); if (cur_head == work->next) break; work->next = cur_head; } }I have written similar code dozens of times, I very intentionally made the code simple so it would be obviously correct. But when I even slightly tweaked the queue_work function, the issue vanished. That wasn’t good enough, I needed to know what was going on.Here is the “fixed” version of the queue_work function:void queue_work_fixed(struct workitem* work) { while (1) { struct workitem* cur_head = IoRing.head; work->next = cur_head; if (InterlockedCompareExchangePointer( &IoRing.head, work, cur_head) == cur_head) break; } }This is functionally the same thing. Look at those two functions! There shouldn’t be a difference between them. I pulled up the assembly output for those functions and stared at it for a long while.1 work$ = 8 2 queue_work_fixed PROC ; COMDAT 3 npad 2 4 $LL2@queue_work: 5 mov rax, QWORD PTR IoRing+32 6 mov QWORD PTR [rcx+8], rax 7 lock cmpxchg QWORD PTR IoRing+32, rcx 8 jne SHORT $LL2@queue_work 9 ret 0 10 queue_work_fixed ENDPA total of ten lines of assembly. Here is what is going on:Line 5 - we read the IoRing.head into register rax (representing cur_head).Line 6 - we write the rax register (representing cur_head) to work->next.Line 7 - we compare-exchange the value of IoRing.head with the value in rcx (work) using rax (cur_head) as the comparand.Line 8 - if we fail to update, we jump to line 5 again and re-try.That is about as simple a code as you can get, and exactly expresses the intent in the C code. However, if I’m looking at the original version, we have:1 work$ = 8 2 queue_work_origin PROC ; COMDAT 3 npad 2 4 $LL2@queue_work_origin: 5 mov rax, QWORD PTR IoRing+32 6 mov QWORD PTR [rcx+8], rax ; ↓↓↓↓↓↓↓↓↓↓↓↓↓ 7 mov rax, QWORD PTR IoRing+32 ; ↑↑↑↑↑↑↑↑↑↑↑↑↑ 8 lock cmpxchg QWORD PTR IoRing+32, rcx 9 cmp rax, QWORD PTR [rcx+8] 10 jne SHORT $LL2@queue_work_origin 11 ret 0 12 queue_work_origin ENDPThis looks mostly the same, right? But notice that we have just a few more lines. In particular, lines 7, 9, and 10 are new. Because we are using a field, we cannot compare to cur_head directly like we previously did but need to read work->next again on lines 9 &10. That is fine.What is not fine is line 7. Here we are reading IoRing.headagain, and work->next may point to another value. In other words, if I were to decompile this function, I would have:void queue_work_origin_decompiled(struct workitem* work) { while (true) { work->next = IoRing.head; // ↓↓↓↓↓↓↓↓↓↓↓↓↓ struct workitem* tmp = IoRing.head; // ↑↑↑↑↑↑↑↑↑↑↑↑↑ struct workitem* cur_head = InterlockedCompareExchangePointer( &IoRing.head, work, tmp); if (cur_head == work->next) break; } }Note the new tmp variable? Why is it reading this twice? It changes the entire meaning of what we are trying to do here. You can look at the output directly in the Compiler Explorer.This smells like a compiler bug. I also checked the assembly output of clang, and it doesn’t have this behavior.I opened a feedback item with MSVC to confirm, but the evidence is compelling. Take a look at this slightly different version of the original. Instead of using a global variable in this function, I’m passing the pointer to it. void queue_work_origin_pointer( struct IoRingSetup* ring, struct workitem* work) { while (1) { struct workitem* cur_head = ring->head; work->next = cur_head; if (InterlockedCompareExchangePointer( &ring->head, work, work->next) == work->next) break; } }And here is the assembly output, without the additional load. ring$ = 8 work$ = 16 queue_work_origin PROC ; COMDAT prefetchw BYTE PTR [rcx+32] npad 12 $LL2@queue_work: mov rax, QWORD PTR [rcx+32] mov QWORD PTR [rdx+8], rax lock cmpxchg QWORD PTR [rcx+32], rdx cmp rax, QWORD PTR [rdx+8] jne SHORT $LL2@queue_work ret 0 queue_work_origin ENDPThat unexpected load was breaking our thread-safety assumptions, and that led to a whole mess of trouble. Violated invariants are no joke. The actual fix was pretty simple, as you can see. Finding it was a huge hurdle. The good news is that I got really familiar with this code, to the point that I got some good ideas on how to improve it further 🙂.