Created attachment 270741 [details] poudriere log while building cad/OrcaSlicer in poudriere, /usr/bin/c++ crashed (see details in the attached poudriere log): #8 0x0000026cef3130d4 raise /usr/local/poudriere/jails/16amd64/usr/src/lib/libc/gen/raise.c:0:10 #9 0x0000026cef3c4de9 abort /usr/local/poudriere/jails/16amd64/usr/src/lib/libc/stdlib/abort.c:67:17 #10 0x0000026cef2f5c11 (/lib/libc.so.7+0xabc11) #11 0x0000026ce38248f2 (/usr/lib/libprivateclang.so.21+0x34248f2) #12 0x0000026ce381f4d5 clang::ASTDeclReader::Visit(clang::Decl*) /usr/local/poudriere/jails/16amd64/usr/src/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp:531:34 #13 0x0000026ce2237c4f clang::StackExhaustionHandler::runWithSufficientStackSpace(clang::SourceLocation, llvm::function_ref<void ()>) /usr/local/poudriere/jails/16amd64/usr/src/contrib/llvm-project/llvm/include/llvm/ADT/STLFunctionalExtras.h:0:12 #14 0x0000026ce384874a clang::ASTReader::ReadDeclRecord(clang::GlobalDeclID) /usr/local/poudriere/jails/16amd64/usr/src/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp:4244:40 #15 0x0000026ce37cff3b clang::ASTReader::GetDecl(clang::GlobalDeclID) /usr/local/poudriere/jails/16amd64/usr/src/contrib/llvm-project/clang/lib/Serialization/ASTReader.cpp:0:5 The base system is from 2026-05-05, 658bb99db9c7 n285700. I will update the system now to the latest main (both base and ports) and rerun the bulk poudriere build to see, if it still there (the results will be in ~10 days).
The log contains an assertion failure report (and command text) before the backtrace: Assertion failed: (Reader.getContext().getLangOpts().Modules && "already deserialized this template specialization"), function VisitFunctionDecl, file /usr/local/poudriere/jails/16amd64/usr/src/contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp, line 993.
(In reply to Mark Millard from comment #1) Hi! Good catch, thanks! I have not noticed this output glued to the previous compile command!
*** This bug has been marked as a duplicate of bug 294281 ***
Sorry, this was the wrong one. I heard about this assertion from bapt@ before, and didn't look enough at bug 294281, which is about an assertion in OrcaSclicer itself. The problem is in llvm's precompiled headers, and while I have been able to reproduce it, it is very hard to pin down a reproduction case for submitting upstream. For now, I think the easiest way to avoid the assertion is to disable precompiled headers, but I'm unsure how to effectively do that in the port.
Created attachment 270766 [details] cad/OrcaSlicer: fix build with clang 21
Please try that patch, which works around the problem by disabling precompiled headers for now.
(In reply to Dimitry Andric from comment #6) Thank you for the quick reply! I will try the patch in a day (the build machine is busy testing math/labplot fix on main ATM :)
Created attachment 270864 [details] successful (reduced) poudriere build log Hi! With the proposed patch cad/OrcaSlicer builds fine on CURRENT, no /usr/bin/c++ crashes! Because this is not a fix, but just a workaround, I will leave this PR still open. As for the proposed workaround patch, I will move the discussion into the bug #294281, it looks more appropriate now!
Meanwhile I reported the assertion upstream. For people who are interested: https://github.com/llvm/llvm-project/issues/198133
(In reply to Dimitry Andric from comment #9) Thank you for the reference, I will repost it in bug #294281!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=86326398b73b81f84831fb5fc4c12d9219bc0f57 commit 86326398b73b81f84831fb5fc4c12d9219bc0f57 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2026-06-01 17:10:11 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2026-06-01 17:10:11 +0000 Merge commit 63c29df8eceb from llvm git (by Dmitry Polukhin): [Serialization] Fix assertion on re-deserialized friend template spec… (#200566) …ialization in PCH (#198133) A friend function-template specialization declared inside a class template is serialized into a PCH. When the class template is later instantiated while loading the PCH, the friend specialization can be deserialized re-entrantly (VisitFriendDecl -> VisitFunctionDecl -> ... -> VisitFunctionDecl for the same specialization) at the same time as the canonical copy, producing two redeclarations of the same specialization in the template's specialization set. ASTDeclReader::VisitFunctionDecl asserted that this collision could only happen when merging declarations from different modules. Since 38b3d87bd384, friend functions defined inside dependent class templates are loaded eagerly, so the collision can now also occur within a single PCH/AST file (non-modules build), tripping the assertion: Assertion failed: (Reader.getContext().getLangOpts().Modules && "already deserialized this template specialization"), function VisitFunctionDecl The merge that follows (mergeRedeclarable) already links the two redeclarations correctly regardless of whether modules are enabled, so the fix is to drop the modules-only assumption and let the merge run. Fixes https://github.com/llvm/llvm-project/issues/198133 This fixes (well, simply removes :) an assertion when building the cad/OrcaSlicer port with precompiled headers turned on. PR: 295296 MFC after: 3 days contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp | 2 -- 1 file changed, 2 deletions(-)
A commit in branch stable/15 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=2cdb0c07e25b5b4782a94e18abf5d39e763a1b13 commit 2cdb0c07e25b5b4782a94e18abf5d39e763a1b13 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2026-06-01 17:10:11 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2026-06-04 08:20:21 +0000 Merge commit 63c29df8eceb from llvm git (by Dmitry Polukhin): [Serialization] Fix assertion on re-deserialized friend template spec… (#200566) …ialization in PCH (#198133) A friend function-template specialization declared inside a class template is serialized into a PCH. When the class template is later instantiated while loading the PCH, the friend specialization can be deserialized re-entrantly (VisitFriendDecl -> VisitFunctionDecl -> ... -> VisitFunctionDecl for the same specialization) at the same time as the canonical copy, producing two redeclarations of the same specialization in the template's specialization set. ASTDeclReader::VisitFunctionDecl asserted that this collision could only happen when merging declarations from different modules. Since 38b3d87bd384, friend functions defined inside dependent class templates are loaded eagerly, so the collision can now also occur within a single PCH/AST file (non-modules build), tripping the assertion: Assertion failed: (Reader.getContext().getLangOpts().Modules && "already deserialized this template specialization"), function VisitFunctionDecl The merge that follows (mergeRedeclarable) already links the two redeclarations correctly regardless of whether modules are enabled, so the fix is to drop the modules-only assumption and let the merge run. Fixes https://github.com/llvm/llvm-project/issues/198133 This fixes (well, simply removes :) an assertion when building the cad/OrcaSlicer port with precompiled headers turned on. PR: 295296 MFC after: 3 days (cherry picked from commit 86326398b73b81f84831fb5fc4c12d9219bc0f57) contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp | 2 -- 1 file changed, 2 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a8e709c667693508a31e2e3a9857a1b8f0587c3e commit a8e709c667693508a31e2e3a9857a1b8f0587c3e Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2026-06-01 17:10:11 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2026-06-04 08:20:25 +0000 Merge commit 63c29df8eceb from llvm git (by Dmitry Polukhin): [Serialization] Fix assertion on re-deserialized friend template spec… (#200566) …ialization in PCH (#198133) A friend function-template specialization declared inside a class template is serialized into a PCH. When the class template is later instantiated while loading the PCH, the friend specialization can be deserialized re-entrantly (VisitFriendDecl -> VisitFunctionDecl -> ... -> VisitFunctionDecl for the same specialization) at the same time as the canonical copy, producing two redeclarations of the same specialization in the template's specialization set. ASTDeclReader::VisitFunctionDecl asserted that this collision could only happen when merging declarations from different modules. Since 38b3d87bd384, friend functions defined inside dependent class templates are loaded eagerly, so the collision can now also occur within a single PCH/AST file (non-modules build), tripping the assertion: Assertion failed: (Reader.getContext().getLangOpts().Modules && "already deserialized this template specialization"), function VisitFunctionDecl The merge that follows (mergeRedeclarable) already links the two redeclarations correctly regardless of whether modules are enabled, so the fix is to drop the modules-only assumption and let the merge run. Fixes https://github.com/llvm/llvm-project/issues/198133 This fixes (well, simply removes :) an assertion when building the cad/OrcaSlicer port with precompiled headers turned on. PR: 295296 MFC after: 3 days (cherry picked from commit 86326398b73b81f84831fb5fc4c12d9219bc0f57) contrib/llvm-project/clang/lib/Serialization/ASTReaderDecl.cpp | 2 -- 1 file changed, 2 deletions(-)
*** Bug 295873 has been marked as a duplicate of this bug. ***
Hi! Thank you for the fix! (Although the discussion on llvm github was not so much convincing to me :) I have got only now to try to rebuild OrcaSlicer. I used a stock version from the ports tree with a stock version of wxgtk32. It builds fine, even without two patch files originally proposed by you: patch-src_libslic3r_LocalesUtils.cpp patch-src_slic3r_Config_Version.cpp I confirm that this bug is fixed, now back to run-testing OrcaSlicer!
(In reply to Alexey Shuvaev from comment #15) Hello, My two proposed patches patch-src_libslic3r_LocalesUtils.cpp patch-src_slic3r_Config_Version.cpp are not supposed to fix the problem reported in this PR: they are needed to chase the upgrade of cad/opencascade to v.8.0.0, as explained in PR 295913.
(In reply to Thierry Thomas from comment #16) Thank you for the heads-up! Moving discussion into bug #295913