A corrupted linked list caused .NET createdump to consume 100% CPU forever
A corrupted linked list in the .NET createdump tool caused it to enter an infinite loop, resulting in 100% CPU usage. This issue was traced back to a missing safety assumption regarding the link_map structure during crash handling. An upstream fix has been implemented to prevent such infinite loops in the future.
- ▪The createdump tool is responsible for generating crash dumps in .NET applications on Linux.
- ▪A cyclic link_map structure led to an unbounded loop, preventing the generation of crash dumps.
- ▪The upstream fix introduces a traversal bound to ensure deterministic termination and protect against cyclic structures.
Opening excerpt (first ~120 words) tap to expand
A corrupted linked list caused .NET createdump to consume 100% CPU foreverI triggered a 100% CPU infinite loop in .NET createdump — and it got fixed upstreamRuwanpurage Pawan RanasingheMay 29, 2026ShareA few days ago, I was debugging a Linux process that behaved unexpectedly during crash handling.Thanks for reading Ruwanpurage's Substack! Subscribe for free to receive new posts and support my work.SubscribeInstead of producing a crash dump, the process entered a state where CPU usage remained pinned at 100%, and the dump generation never completed.That investigation led into the internals of the .NET runtime’s Linux crash tool: createdump.The result was a reproducible infinite traversal condition in ELF loader enumeration logic, later confirmed and fixed in the upstream dotnet/runtime…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Hacker News (Newest).
Discussion
0 commentsMore from Hacker News (Newest)
