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
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
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
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
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
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
that referenced
this issue
Mar 31, 2025
Fix llvm#132059. Providing incorrect mappings via -fmodule-file=<name>=<path/to/bmi>, such that the BMI file corresponds to a different module which transitively imports the specified module, could previously crash the compiler. The crash is caused during serialization, when trying to resolve declaration IDs in the AST body after having loaded the wrong module. This commit fixes the issue by checking the module's identity while reading the AST's control block and erroring out if a mismatch is detected.
naveen-seth
added a commit
to naveen-seth/llvm-project
that referenced
this issue
Apr 2, 2025
Fix llvm#132059. Providing incorrect mappings via `-fmodule-file=<name>=<path/to/bmi>` can crash the compiler when loading a module that imports an incorrectly mapped module. The crash occurs during AST body deserialization, when the compiler attempts to resolve remappings using the `ModuleFile` from the incorrectly mapped module's BMI file. The cause is an invalid access into an incorrectly loaded `ModuleFile`. This commit fixes the issue by verifying that the mapped BMI files correspond to the mapped-from modules as soon as the module name is read from the BMI's control block, and it errors out if there is a mismatch.
naveen-seth
added a commit
to naveen-seth/llvm-project
that referenced
this issue
Apr 2, 2025
Fix llvm#132059. Providing incorrect mappings via `-fmodule-file=<name>=<path/to/bmi>` can crash the compiler when loading a module that imports an incorrectly mapped module. The crash occurs during AST body deserialization, when the compiler attempts to resolve remappings using the `ModuleFile` from the incorrectly mapped module's BMI file. The cause is an invalid access into an incorrectly loaded `ModuleFile`. This commit fixes the issue by verifying that the mapped BMI files correspond to the mapped-from modules as soon as the module name is read from the BMI's control block, and it errors out if there is a mismatch.
naveen-seth
added a commit
to naveen-seth/llvm-project
that referenced
this issue
Apr 8, 2025
[clang][modules] Guard against invalid -fmodule-file mappings Fixes llvm#132059. Providing incorrect mappings via `-fmodule-file=<name>=<path/to/bmi>` can cause the compiler to crash when loading a module that imports an incorrectly mapped module. The crash occurs during AST body deserialization when the compiler attempts to resolve remappings using the `ModuleFile` from the incorrectly mapped module's BMI file. The cause is an invalid access into an incorrectly loaded `ModuleFile`. This commit fixes the issue by verifying the identity of the imported module.
naveen-seth
added a commit
to naveen-seth/llvm-project
that referenced
this issue
Apr 8, 2025
[clang][modules] Guard against invalid -fmodule-file mappings Fixes llvm#132059. Providing incorrect mappings via `-fmodule-file=<name>=<path/to/bmi>` can cause the compiler to crash when loading a module that imports an incorrectly mapped module. The crash occurs during AST body deserialization when the compiler attempts to resolve remappings using the `ModuleFile` from the incorrectly mapped module's BMI file. The cause is an invalid access into an incorrectly loaded `ModuleFile`. This commit fixes the issue by verifying the identity of the imported module.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this issue
Apr 8, 2025
…(#132059) (#133462) Fix llvm/llvm-project#132059. Providing incorrect mappings via `-fmodule-file=<name>=<path/to/bmi>` can crash the compiler when loading a module that imports an incorrectly mapped module. The crash occurs during AST body deserialization, when the compiler attempts to resolve remappings using the `ModuleFile` from the incorrectly mapped module's BMI file. The cause is an invalid access into an incorrectly loaded `ModuleFile`. This commit fixes the issue by verifying the identity of the imported module.
qiaojbao
pushed a commit
to GPUOpen-Drivers/llvm-project
that referenced
this issue
Apr 29, 2025
Local branch origin/amd-gfx 1602708 Merged main:707367621679 into origin/amd-gfx:4cab0b6fa1ab Remote branch main ac42b08 [clang][modules] Guard against bad -fmodule-file mappings (llvm#132059) (llvm#133462)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
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: