clang frontend crash while a second crafter-build ran on the machine (5.0.0; seen twice; the shared input not located) #49

New issue

Open

opened 2026-11-01 19:52:09 +00:00 by jorijnvdgraaf · 2 comments

jorijnvdgraaf commented

2026-11-01 19:52:09 +00:00

Owner

What happened. During crafter-build (the //stable 5.0.0 flatpak) on imsd-messages, compiling interfaces/ImsdMessages.Ui-App.cppm, clang died with "clang frontend command failed due to signal". The stack dump has it instantiating std::optional<ImsdMessages::Ui::FrameDriver> out of the std module (optional:957 / optional:384) while parsing the App class. The project's crafter-build test started right after and compiled the same unit without a word; the build has been green on every other run of the same commit.

At that moment a second crafter-build was running on the machine from another terminal: flatpak run --branch=local net.catcrafts.CrafterBuild (also 5.0.0) on another project, and crafter-build --local test in the Crafter.Build checkout (its fixture projects under ~/.cache/review-gate0/flatpak-debug-tools/tmp/). The same symptom under the same condition was seen once before, 2026-10-21 (noted then as "//local and //stable at once").

What I could and could not establish.

All three installed branches (stable, beta, local) are 5.0.0 and one flatpak app id, so they share ~/.var/app/net.catcrafts.CrafterBuild/cache/crafter.build/ — the toolchain dirs (each with a .lock) and external/ (the dependencies' clones and built modules).
In the crash's minute nothing under external/ was rewritten except the unpinned dependencies' .git/FETCH_HEADs, which this project's own build and test steps write at their start (confirmed by the timestamps of the later steps). Each project's std.pcm is in its own bin/ dir.
So the input the two builds would have shared is not located. Two coincidences in two weeks, and a crash that does not recur on retry; it could also be a non-deterministic clang 23.1.2 crash with nothing shared.

Stack excerpt

1.  interfaces/ImsdMessages.Ui-App.cppm:30:175: current parser token '{'
2.  interfaces/ImsdMessages.Ui-App.cppm:27:8: parsing namespace 'ImsdMessages'
3.  interfaces/ImsdMessages.Ui-App.cppm:28:5: parsing struct/union/class body 'ImsdMessages::Ui::App'
4.  /app/bin/../include/c++/v1/optional:957:35: instantiating function definition 'std::__1::optional<ImsdMessages::Ui::FrameDriver>::optional'
5.  /app/bin/../include/c++/v1/optional:384:55: instantiating function definition 'std::__optional_destruct_base<ImsdMessages::Ui::FrameDriver>::~__optional_destruct_base'
…
#126 llvm::CrashRecoveryContext::RunSafely (libLLVM.so.23.1)
#128 clang::driver::Compilation::ExecuteCommand
clang++: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 23.1.2, Target: x86_64-unknown-linux-gnu

Ask. Whether two crafter-build runs on one machine (any branches, any projects) share a file one of them writes while the other compiles — the toolchain dir past its .lock's span, a dependency's checkout or module in external/, anything under the cache — and if so, a lock for the build's span or per-build artifact dirs. If nothing is shared, this is a clang crash to report upstream with a reproducer, and the two coincidences are just that.

**What happened.** During `crafter-build` (the `//stable` 5.0.0 flatpak) on imsd-messages, compiling `interfaces/ImsdMessages.Ui-App.cppm`, clang died with "clang frontend command failed due to signal". The stack dump has it instantiating `std::optional<ImsdMessages::Ui::FrameDriver>` out of the std module (`optional:957` / `optional:384`) while parsing the `App` class. The project's `crafter-build test` started right after and compiled the same unit without a word; the build has been green on every other run of the same commit. At that moment a second crafter-build was running on the machine from another terminal: `flatpak run --branch=local net.catcrafts.CrafterBuild` (also 5.0.0) on another project, and `crafter-build --local test` in the Crafter.Build checkout (its fixture projects under `~/.cache/review-gate0/flatpak-debug-tools/tmp/`). The same symptom under the same condition was seen once before, 2026-10-21 (noted then as "//local and //stable at once"). **What I could and could not establish.** - All three installed branches (stable, beta, local) are 5.0.0 and one flatpak app id, so they share `~/.var/app/net.catcrafts.CrafterBuild/cache/crafter.build/` — the toolchain dirs (each with a `.lock`) and `external/` (the dependencies' clones and built modules). - In the crash's minute nothing under `external/` was rewritten except the unpinned dependencies' `.git/FETCH_HEAD`s, which this project's own build and test steps write at their start (confirmed by the timestamps of the later steps). Each project's `std.pcm` is in its own `bin/` dir. - So the input the two builds would have shared is not located. Two coincidences in two weeks, and a crash that does not recur on retry; it could also be a non-deterministic clang 23.1.2 crash with nothing shared. **Stack excerpt** ``` 1. interfaces/ImsdMessages.Ui-App.cppm:30:175: current parser token '{' 2. interfaces/ImsdMessages.Ui-App.cppm:27:8: parsing namespace 'ImsdMessages' 3. interfaces/ImsdMessages.Ui-App.cppm:28:5: parsing struct/union/class body 'ImsdMessages::Ui::App' 4. /app/bin/../include/c++/v1/optional:957:35: instantiating function definition 'std::__1::optional<ImsdMessages::Ui::FrameDriver>::optional' 5. /app/bin/../include/c++/v1/optional:384:55: instantiating function definition 'std::__optional_destruct_base<ImsdMessages::Ui::FrameDriver>::~__optional_destruct_base' … #126 llvm::CrashRecoveryContext::RunSafely (libLLVM.so.23.1) #128 clang::driver::Compilation::ExecuteCommand clang++: error: clang frontend command failed due to signal (use -v to see invocation) clang version 23.1.2, Target: x86_64-unknown-linux-gnu ``` **Ask.** Whether two crafter-build runs on one machine (any branches, any projects) share a file one of them writes while the other compiles — the toolchain dir past its `.lock`'s span, a dependency's checkout or module in `external/`, anything under the cache — and if so, a lock for the build's span or per-build artifact dirs. If nothing is shared, this is a clang crash to report upstream with a reproducer, and the two coincidences are just that.

jorijnvdgraaf commented

2026-11-01 20:59:16 +00:00

Author

Owner

Second occurrence, 2026-11-01 21:57 — the same unit, the same point, again while a crafter-build --local from another terminal ran (Crafter.Build's own checkout, ~/repos/Crafter/Crafter.Build/bin/crafter.build-exe-…/crafter-build --local), and again crafter-build test right after compiled the same unit without a word.

This time the inner frames are on record (the first time only the driver's outer frames were read before the log was overwritten):

[36/36] Compiling interface ImsdMessages.Ui
Stack dump:
1.  interfaces/ImsdMessages.Ui-App.cppm:31:175: current parser token '{'
2.  interfaces/ImsdMessages.Ui-App.cppm:28:8: parsing namespace 'ImsdMessages'
3.  interfaces/ImsdMessages.Ui-App.cppm:29:5: parsing struct/union/class body 'ImsdMessages::Ui::App'
4.  /app/bin/../include/c++/v1/optional:957:35: instantiating function definition 'std::__1::optional<ImsdMessages::Ui::FrameDriver>::optional'
5.  /app/bin/../include/c++/v1/optional:384:55: instantiating function definition 'std::__optional_destruct_base<ImsdMessages::Ui::FrameDriver>::~__optional_destruct_base'
  #3 (libc.so.6+0x42770)                                  — the signal handler
  #4 clang::ASTContext::getCanonicalTagType(clang::TagDecl const*) const   (libclang-cpp.so.23.1+0xe6d6fe)
  #5 clang::ASTContext::getTagType(clang::ElaboratedTypeKeyword, clang::NestedNameSpecifier, clang::TagDecl const*, bool) const
clang++: error: clang frontend command failed due to signal

So it is a segfault inside clang's AST (getCanonicalTagType on a TagDecl) while instantiating a libc++ template out of the std module for the project's largest module interface — not an I/O error on a module file. The std module this unit imports is the project's own (./bin/imsd-messages-ui-…/std.pcm, built earlier in the same run), which the other build cannot touch; what the two runs share is the toolchain under ~/.var/app/net.catcrafts.CrafterBuild/cache/crafter.build/x86_64-unknown-linux-gnu-native-23.1.2-7dd3cdd8/ (libc++'s headers and module sources, past its .lock's span?) and the machine's memory and page cache. Two for two under a concurrent build, zero crashes in the ~40 solitary builds of the same tree today; an LLVM bug with modules that only shows under load is as consistent with this as a shared file. The step's log is kept this time (captures/2026-11-01-first-push-r37/fixset/p30m-build-crash.log in the fp6 journal).

**Second occurrence, 2026-11-01 21:57** — the same unit, the same point, again while a `crafter-build --local` from another terminal ran (Crafter.Build's own checkout, `~/repos/Crafter/Crafter.Build/bin/crafter.build-exe-…/crafter-build --local`), and again `crafter-build test` right after compiled the same unit without a word. This time the inner frames are on record (the first time only the driver's outer frames were read before the log was overwritten): ``` [36/36] Compiling interface ImsdMessages.Ui Stack dump: 1. interfaces/ImsdMessages.Ui-App.cppm:31:175: current parser token '{' 2. interfaces/ImsdMessages.Ui-App.cppm:28:8: parsing namespace 'ImsdMessages' 3. interfaces/ImsdMessages.Ui-App.cppm:29:5: parsing struct/union/class body 'ImsdMessages::Ui::App' 4. /app/bin/../include/c++/v1/optional:957:35: instantiating function definition 'std::__1::optional<ImsdMessages::Ui::FrameDriver>::optional' 5. /app/bin/../include/c++/v1/optional:384:55: instantiating function definition 'std::__optional_destruct_base<ImsdMessages::Ui::FrameDriver>::~__optional_destruct_base' #3 (libc.so.6+0x42770) — the signal handler #4 clang::ASTContext::getCanonicalTagType(clang::TagDecl const*) const (libclang-cpp.so.23.1+0xe6d6fe) #5 clang::ASTContext::getTagType(clang::ElaboratedTypeKeyword, clang::NestedNameSpecifier, clang::TagDecl const*, bool) const clang++: error: clang frontend command failed due to signal ``` So it is a segfault inside clang's AST (`getCanonicalTagType` on a `TagDecl`) while instantiating a libc++ template out of the std module for the project's largest module interface — not an I/O error on a module file. The std module this unit imports is the project's own (`./bin/imsd-messages-ui-…/std.pcm`, built earlier in the same run), which the other build cannot touch; what the two runs share is the toolchain under `~/.var/app/net.catcrafts.CrafterBuild/cache/crafter.build/x86_64-unknown-linux-gnu-native-23.1.2-7dd3cdd8/` (libc++'s headers and module sources, past its `.lock`'s span?) and the machine's memory and page cache. Two for two under a concurrent build, zero crashes in the ~40 solitary builds of the same tree today; an LLVM bug with modules that only shows under load is as consistent with this as a shared file. The step's log is kept this time (`captures/2026-11-01-first-push-r37/fixset/p30m-build-crash.log` in the fp6 journal).

jorijnvdgraaf commented

2026-11-01 21:16:12 +00:00

Author

Owner

Third occurrence, 2026-11-01 22:14 — with NO other crafter-build running on the machine, which retires the concurrent-build theory of this issue's title. Same unit (ImsdMessages.Ui-App.cppm, the App class), a different point and a different frame:

1.  interfaces/ImsdMessages.Ui-App.cppm:876:44: current parser token ';'
3.  interfaces/ImsdMessages.Ui-App.cppm:29:5: parsing struct/union/class body 'ImsdMessages::Ui::App'
4.  /app/bin/../include/c++/v1/optional:868:36: instantiating class definition 'std::__1::optional<ImsdMessages::Ui::WaylandSource>'
5.  /app/bin/../include/c++/v1/optional:773:8: instantiating class definition 'std::__optional_iterator_base<ImsdMessages::Ui::WaylandSource>'
  #4 clang::Decl::castFromDeclContext(clang::DeclContext const*)   (libclang-cpp.so.23.1+0x1097b04)
  #5 clang::Decl::getTemplateDepth() const
clang++: error: clang frontend command failed due to signal

Three crashes in about fifteen builds of this tree since 20:39, all segfaults inside clang's AST while instantiating a libc++ optional<T> out of the std module for the project's largest module interface, each at a different member, each gone on the immediate retry; none in the day's earlier builds of the same project. So: a non-deterministic clang 23.1.2 frontend crash with C++26 modules (dangling or uninitialised AST state when deserialising the std module's templates — the two frames, getCanonicalTagType on a TagDecl and castFromDeclContext, both read a decl that is not there), not a shared file. What Crafter.Build could do about it is a retry of a compile step that dies by signal (once; the log says so) before failing the build; the crash itself belongs upstream with a reproducer, which a non-deterministic one does not give. The logs: captures/2026-11-01-first-push-r37/fixset/p30m-build-crash.log and p31m-build-crash.log in the fp6 journal.

**Third occurrence, 2026-11-01 22:14 — with NO other crafter-build running on the machine**, which retires the concurrent-build theory of this issue's title. Same unit (`ImsdMessages.Ui-App.cppm`, the `App` class), a different point and a different frame: ``` 1. interfaces/ImsdMessages.Ui-App.cppm:876:44: current parser token ';' 3. interfaces/ImsdMessages.Ui-App.cppm:29:5: parsing struct/union/class body 'ImsdMessages::Ui::App' 4. /app/bin/../include/c++/v1/optional:868:36: instantiating class definition 'std::__1::optional<ImsdMessages::Ui::WaylandSource>' 5. /app/bin/../include/c++/v1/optional:773:8: instantiating class definition 'std::__optional_iterator_base<ImsdMessages::Ui::WaylandSource>' #4 clang::Decl::castFromDeclContext(clang::DeclContext const*) (libclang-cpp.so.23.1+0x1097b04) #5 clang::Decl::getTemplateDepth() const clang++: error: clang frontend command failed due to signal ``` Three crashes in about fifteen builds of this tree since 20:39, all segfaults inside clang's AST while instantiating a libc++ `optional<T>` out of the std module for the project's largest module interface, each at a different member, each gone on the immediate retry; none in the day's earlier builds of the same project. So: a non-deterministic clang 23.1.2 frontend crash with C++26 modules (dangling or uninitialised AST state when deserialising the std module's templates — the two frames, `getCanonicalTagType` on a `TagDecl` and `castFromDeclContext`, both read a decl that is not there), not a shared file. What Crafter.Build could do about it is a retry of a compile step that dies by signal (once; the log says so) before failing the build; the crash itself belongs upstream with a reproducer, which a non-deterministic one does not give. The logs: `captures/2026-11-01-first-push-r37/fixset/p30m-build-crash.log` and `p31m-build-crash.log` in the fp6 journal.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Catcrafts/Crafter.Build#49

No description provided.

Rows
Columns