clangd: clangd crashes on trivial `constexpr` declaration (windows)
clangd crashes on the camera_option_default_value variable. Interestingly enough, it does not crash if the constant is renamed to (for example) default_value. Just from playing around it appears to be somewhat related to the length of the line (or name?).
// header1.hxx
#pragma once
constexpr const char* const camera_option_default_value = "-";
// header2.hxx
#pragma once
#include <header1.hxx>
Logs
[11:50:02.821] Building preamble...
Exception Code: 0xC0000005
#0 0x00007ff696d19efc (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e49efc)
#1 0x00007ff696d19c6b (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e49c6b)
#2 0x00007ff696d19c0b (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e49c0b)
#3 0x00007ff696d19c6b (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e49c6b)
#4 0x00007ff696d19c6b (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e49c6b)
#5 0x00007ff696d0e928 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e3e928)
#6 0x00007ff696d0fe05 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e3fe05)
#7 0x00007ff696d163b1 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e463b1)
#8 0x00007ff696cf00eb (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e200eb)
#9 0x00007ff696cee01e (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e1e01e)
#10 0x00007ff696cd432e (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1e0432e)
#11 0x00007ff696b947fe (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1cc47fe)
#12 0x00007ff696c18fa7 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1d48fa7)
#13 0x00007ff696b6aed7 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1c9aed7)
#14 0x00007ff696b6a9cb (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1c9a9cb)
#15 0x00007ff696b92d42 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1cc2d42)
#16 0x00007ff695d7d4f3 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0xead4f3)
#17 0x00007ff694f803e9 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0xb03e9)
#18 0x00007ff694f82177 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0xb2177)
#19 0x00007ff694f774ba (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0xa74ba)
#20 0x00007ff696a95af0 (C:\Users\fho\AppData\Local\Microsoft\WinGet\Links\clangd.exe+0x1bc5af0)
#21 0x00007ff9f48d26ad (C:\WINDOWS\System32\KERNEL32.DLL+0x126ad)
#22 0x00007ff9f63ea9f8 (C:\WINDOWS\SYSTEM32\ntdll.dll+0x5a9f8)
Segmentation fault
System information
Output of clangd --version:
clangd version 16.0.2
Editor/LSP plugin:
Operating system: Windows 11
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 21
Thanks for checking! I submitted the patch for review.
Just to address this point: no, clangd cannot currently be built standalone, though I’ve suggested this in https://github.com/clangd/clangd/discussions/1375.
However, even if that were possible, it would not have been very helpful in this case, since the crash is not directly in clangd code, but in clang code invoked by clangd code (in the stack trace you posted, everything above frame 34 is clang code). With a hypothetical standalone build, those frames would be in a prebuilt clang library and so presumably wouldn’t be symbolized.
That said, it shouldn’t be necessary to do a local build to get a symbolized stack trace; having
llvm-symbolizerin the PATH should be sufficient (though I’ve heard users report this not working on Windows; I’m not sure why).Anyways, it’s great for debugging purposes that you have a local build! I’ll have a look at your findings and see if I can suggest something to try.