Issue 107434
Summary clang-format can consume an unreasonable amount of memory when ColumnLimit != 0
Labels clang-format
Assignees
Reporter nicolas-guichard
    Using the attached [reproducer.c](https://github.com/user-attachments/files/16897629/reproducer.txt):
```
> time -v clang-format --style='{ColumnLimit: 0}' reproducer.c
User time (seconds): 0.56
Maximum resident set size (kbytes): 265132 (265 MB)

> time -v clang-format --style='{ColumnLimit: 80}' reproducer.c
User time (seconds): 68.73
Maximum resident set size (kbytes): 13737072 (13.7 GB, 51× increase)
```

That reproducer is certainly special, being more than 2 MB on a single line. It is the result of a macro expansion in WebKit's [bmalloc_heap_config.h](https://searchfox.org/wubkat/rev/b36cbce69fddb7da33823f316bd8ead5bebee970/Source/bmalloc/libpas/src/libpas/bmalloc_heap_config.h). We encountered this when trying to expose macro expansions in Searchfox, leading to https://bugzilla.mozilla.org/show_bug.cgi?id=1912078. Our clang plugin uses `clang::format::reformat`.

I think bailing out when a line is too complex to be broken down would be a good first step. I see [OptimizingLineFormatter](https://searchfox.org/llvm/rev/c2b92a4250b3f514685676ba8985ea73450f14d3/clang/lib/Format/UnwrappedLineFormatter.cpp#1245-1246) has that kind of logic already.
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs

Reply via email to