Csharpier CLI consumes insane amounts of RAM if indent_size is set to 0

Hi,
I noticed that when using CSharpier CLI if a .editorconfig has indent_space set to 0 and indent_style is set that Csharpier CLI consumes ever increasing amounts of RAM if run and eventually will crash or cause the system to freeze.

If indent_space is above 0 then there's no issue, it specifically only occurs when it's set to 0.

My Device's specs are:
Intel core i7-1260P (4x P cores + 8x E Cores)
Intel Arc Xe iGPU
48GB DDR5-4800

I have these .NET SDKs installed:

8.0.121 [/usr/lib/dotnet/sdk]
9.0.111 [/usr/lib/dotnet/sdk]
10.0.100-rc.2.25502.107 [/usr/lib/dotnet/sdk]

Environments:

CSharpier Version: 1.1.2
Running CSharpier via: dotnet cli (as global tool)
Operating System: Linux Mint 22.2 (based on Ubuntu 24.04.x LTS)
.csharpierrc Settings:
.editorconfig Settings:

Only indent_size and indent_style are relevant to the issue. Without them Csharpier CLI works normally.

[*.{cs,csx}]
indent_size = 0
indent_style = tab
csharp_style_var_for_built_in_types = false
csharp_style_var_elsewhere = false
dotnet_separate_import_directive_groups = true
max_line_length = 100

Steps to reproduce:

Open a terminal program in a .NET project directory
Add the .editorconfig file with the configured indent_size and indent_style settings
Run csharpier format . in the terminal

Expected behavior:
Should run normally and complete within a few seconds.

Actual behavior:
Increasingly consumes more and more RAM (starts under 1GB but have seen it go up much higher) until the system locks up or CSharpier CLI runs out of memory and crashes.

For example:

Hey, I've been able to recreate this on all versions of CSharpier '1.0.0-alpha10 and above (couldn't get older versions to run). Interestingly it will format some files but gets stuck on others.

It appears that this line here is the culprit. It will continue to add \t while there is still space in spacesToAppend. As IndentSize is zero it will never decrease this value and will keep adding tabs until we run out of memory.

while (spacesToAppend > 0 && spacesToAppend >= this.PrinterOptions.IndentSize)
{
    this.Output.Append('\t');
    spacesToAppend -= this.PrinterOptions.IndentSize;
}

It could be fixed with the following

spacesToAppend -= Math.Max(this.PrinterOptions.IndentSize, 1);

I do wonder if PrinterOptions.IndentSize should be constrained to be equal to or greater than 1. I feel like CalculateIndentLength might be a little broken when IndentSize is 0.

Interestingly it will format some files but gets stuck on others.

The relevant code you linked seems to be Comment formatting related, so I would imagine the CLI doesn't get stuck on files that lack specific types of code comment(s).

It appears that this line here is the culprit. It will continue to add \t while there is still space in spacesToAppend. As IndentSize is zero it will never decrease this value and will keep adding tabs until we run out of memory.

Shouldn't spacesToAppend be set to 0 if IndentSize is 0 regardless of whether tabs or spaces is specified?

I do wonder if PrinterOptions.IndentSize should be constrained to be equal to or greater than 1.

For lines containing Code Comments specifically or for any kind of line generally?

I do wonder if PrinterOptions.IndentSize should be constrained to be equal to or greater than 1. I feel like CalculateIndentLength might be a little broken when IndentSize is 0.

I'm in favor of this. I don't see a valid reason to set IndentSize to 0 and there may be other issues that show up when trying to format things with no indentation.

Okay, I can trigger this bug by formatting EditorConfig\GlobMatcherOptions.cs, it appears that documents starting with multi line comments causes this due to the asterisk preceeded by a single space. I imagine it has other triggers, but I don't see any pressing need to find them.

I do wonder if PrinterOptions.IndentSize should be constrained to be equal to or greater than 1. I feel like CalculateIndentLength might be a little broken when IndentSize is 0.

Prettier supports 0 width formatting for both tabs and spaces. Aside from the above bug, it appears that csharpier outputs similar looking code without issue. No idea why you'd want zero width spaces, but it works 😅

I think my above fix should work, alternatively we could skip the while loop when IndentSize is 0, it would make multi line comments look better under these settings. Perhaps setting IndentSize to be at least one when tabs are enabled would prevent other issues 🤷

there may be other issues that show up when trying to format things with no indentation.

When formatting code with indent_size = 0 I found that PrintMethodUnformattedWithoutAttributes would throw an error due to .First() not having a value.

`

I still don't see a valid use case for indent size = 0 regardless of if prettier supports it or not. I'm inclined to just have csharpier throw an exception if it runs into a configuration that tries to set the size to 0.

Hard fail to prevent IndentSize of <= 0 to avoid any issues.

Hard fail to prevent IndentSize of <= 0 to avoid any issues. (#1741)

Navigation Menu

Repository navigation

Csharpier CLI consumes insane amounts of RAM if `indent_size` is set to 0 #1736

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Csharpier CLI consumes insane amounts of RAM if indent_size is set to 0 #1736

Description

Activity

TimothyMakkison commented on Nov 4, 2025

alastairlundy commented on Nov 4, 2025

belav commented on Nov 5, 2025

TimothyMakkison commented on Nov 7, 2025

TimothyMakkison commented on Nov 7, 2025

belav commented on Nov 7, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

Csharpier CLI consumes insane amounts of RAM if `indent_size` is set to 0 #1736