small mistake in -fmodule-file description breaks clang++-19 frontend with -fstack-protector #132059
Labels
clang:modules
C++20 modules and Clang Header Modules
good first issue
https://github.com/llvm/llvm-project/contribute
Comments
EugeneZelenko
added
clang:modules
|
@llvm/issue-subscribers-clang-modules Author: Igor Machado Coelho (igormcoelho)
I was experimenting CXX Modules with Clang 19 on Ubuntu, and it suddently broke when I passed wrong parameters on -fmodule-file, but strangely this only occurred when -fstack-protector was enabled... I have no idea why.
This is the clang version: The files are: First I compile both .pcm files: The bug appears when I mistakenly pass 'std' twice: It breaks with |
What if you pass |
|
This is broken one with bug:
If I keep the buggy one and increment with that:
Bug now changes! That's interesting... And if I try to inject more errors, like -fmodule-file=hello=std.pcm, then it GETS BETTER! hhahaah And just for completeness, this really works fine with no errors: |
ChuanqiXu9
added
crash-on-invalid
good first issue
|
Hi! This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:
If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below. |
|
@llvm/issue-subscribers-good-first-issue Author: Igor Machado Coelho (igormcoelho)
I was experimenting CXX Modules with Clang 19 on Ubuntu, and it suddently broke when I passed wrong parameters on -fmodule-file, but strangely this only occurred when -fstack-protector was enabled... I have no idea why.
This is the clang version: The files are: First I compile both .pcm files: The bug appears when I mistakenly pass 'std' twice: It breaks with |
|
I am relatively busy right now. And this looks like a simple check, diagnose and return pattern to fix this. So I marked it as good-first-issue now. |
|
I have reproduced the crashes using a Debug build of Clang and it is always caused by failing this assert / the following index into I was also able to reproduce the crashes without // hello.cppm
export module hello;
import std;
export inline void do_hello(std::string_view const &name)
{
std::cout << "Hello " << name << "!\n";
}// main.cpp
import std;
int main() {
std::cout << "Hello, World!\n";
return 0;
}clang++ -std=c++20 -stdlib=libc++ --precompile /usr/lib/llvm-19/share/libc++/v1/std.cppm -o std.pcm
clang++ -std=c++20 -stdlib=libc++ --precompile hello.cppm -o hello.pcm -fmodule-file=std=std.pcm
clang++ -v -std=c++20 -stdlib=libc++ main.cpp -fmodule-file=std=hello.pcmFull crash report with diagnostic messages appended: I'd really like to try fixing this. Can I take this issue? |
|
@naveen-seth I say go for it! |
naveen-seth
added a commit
to naveen-seth/llvm-project-fmodule-file-crash-bug
that referenced
this issue
Mar 28, 2025
…llvm#132059) When using -fmodule-file=<name>=<path/to/bmi> with incorrect inputs, the compiler crashes in two scenarios: 1. A module is mapped to the right BMI file but one of its transitively exported module dependencies is also mapped to the same BMI file. 2. A module is mapped to a wrong BMI file which also transitively exports that module. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having imported the wrong module. Because the 2nd scenario can only be detected after reading the BMI's module name, checking for duplicate values while parsing command-line options is not enough to fix the crash. This commit fixes the issue by validating module identity after having read the AST's ControlBlock.
naveen-seth
added a commit
to naveen-seth/llvm-project-fmodule-file-crash-bug
that referenced
this issue
Mar 28, 2025
…llvm#132059) When using -fmodule-file=<name>=<path/to/bmi> with incorrect inputs, the compiler crashes in two scenarios: 1. A module is mapped to the right BMI file but one of its transitively exported module dependencies is also mapped to the same BMI file. 2. A module is mapped to a wrong BMI file which also transitively exports that module. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having imported the wrong module. Because the 2nd scenario can only be detected after reading the BMI's module name, checking for duplicate values while parsing command-line options is not enough to fix the crash. This commit fixes the issue by validating module identity after having read the AST's ControlBlock.
naveen-seth
added a commit
to naveen-seth/llvm-project-fmodule-file-crash-bug
that referenced
this issue
Mar 28, 2025
…llvm#132059) When using -fmodule-file=<name>=<path/to/bmi> with incorrect inputs, the compiler crashes in two scenarios: 1. A module is mapped to the right BMI file but one of its transitively exported module dependencies is also mapped to the same BMI file. 2. A module is mapped to a wrong BMI file which also transitively exports that module. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having imported the wrong module. Because the 2nd scenario can only be detected after reading the BMI's module name, checking for duplicate values while parsing command-line options is not enough to fix the crash. This commit fixes the issue by validating module identity after having read the AST's ControlBlock.
naveen-seth
added a commit
to naveen-seth/llvm-project-fmodule-file-crash-bug
that referenced
this issue
Mar 28, 2025
When using -fmodule-file=<name>=<path/to/bmi> with incorrect inputs, the compiler crashes in two scenarios: 1. A module is mapped to the right BMI file but one of its transitively exported module dependencies is also mapped to the same BMI file. 2. A module is mapped to a wrong BMI file which also transitively exports that module. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having imported the wrong module. Because the 2nd scenario can only be detected after reading the BMI's module name, checking for duplicate values while parsing command-line options is not enough to fix the crash. This commit fixes the issue by validating module identity after having read the AST's ControlBlock.
naveen-seth
added a commit
to naveen-seth/llvm-project-fmodule-file-crash-bug
that referenced
this issue
Mar 28, 2025
When using -fmodule-file=<name>=<path/to/bmi> with incorrect inputs, the compiler crashes in two scenarios: 1. A module is mapped to the right BMI file but one of its transitively exported module dependencies is also mapped to the same BMI file. 2. A module is mapped to a wrong BMI file which also transitively exports that module. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having imported the wrong module. Because the 2nd scenario can only be detected after reading the BMI's module name, checking for duplicate values while parsing command-line options is not enough to fix the crash. This commit fixes the issue by validating module identity after having read the AST's ControlBlock.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was experimenting CXX Modules with Clang 19 on Ubuntu, and it suddently broke when I passed wrong parameters on -fmodule-file, but strangely this only occurred when -fstack-protector was enabled... I have no idea why.
This is the clang version:
The files are:
First I compile both .pcm files:
The bug appears when I mistakenly pass 'std' twice:
It breaks with
1. example/hello-world/main.cc:5:11: current parser token ';'But it seems to occur only if I enable -fstack-protector ... if I remove it, the bug is gone (but error correctly remains):
The text was updated successfully, but these errors were encountered: