Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ninja triggers GLIBCXX assertion and crashes #2472

Closed
ImmanuelHaffner opened this issue Aug 2, 2024 · 2 comments · Fixed by #2489
Closed

Ninja triggers GLIBCXX assertion and crashes #2472

ImmanuelHaffner opened this issue Aug 2, 2024 · 2 comments · Fixed by #2489
Milestone

Comments

@ImmanuelHaffner
Copy link

ImmanuelHaffner commented Aug 2, 2024

Building one of my company's projects, I just had Ninja crash with

/usr/include/c++/14.1.1/bits/stl_vector.h|1130| std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = Node*; _Alloc = std::allocator<Node*>; reference = Node*&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
|| Subprocess aborted
|| CMake Error: Generator: execution of make failed. Make command was: /usr/bin/ninja -j 14 <TARGETS REDACTED>
|| [Finished in 2 seconds with code 1]

I don't remember changing anything on the build configuration side. I am on Ninja version 1.12.1. Compiling the same project in a new clone of the repository in a different paths works flawlessly. It used to work in the original path until now.

The error occurs in my RelWithDebInfo build located in path/to/project/build/RelWithDebInfo. A nearly identically configured Debug build in path/to/project/build/Debug builds just fine.

This issue might be related to #2309, which also reports the same assertion is triggered.

Running the build in the debugger points me to deps_log.cc:

205if (is_deps) {
206assert(size % 4 == 0);
207int* deps_data = reinterpret_cast<int*>(buf);
208int out_id = deps_data[0];
209│       TimeStamp mtime;
210│       mtime = (TimeStamp)(((uint64_t)(unsigned int)deps_data[2] << 32) |
211│                           (uint64_t)(unsigned int)deps_data[1]);
212│       deps_data += 3;
213int deps_count = (size / 4) - 3;
214215│       Deps* deps = new Deps(mtime, deps_count);
216for (int i = 0; i < deps_count; ++i) {
217assert(deps_data[i] < (int)nodes_.size());
218├───────> assert(nodes_[deps_data[i]]);
219│         deps->nodes[i] = nodes_[deps_data[i]];
220│       }
221222│       total_dep_record_count++;
223if (!UpdateDeps(out_id, deps))
224│         ++unique_dep_record_count;
225│     } else {

Sadly, i is optimized out, but it's out of bounds.

UPDATE: After reconfiguring with cmake -S . -B build/RelWithDebInfo -G Ninja --fresh ... the problem persisted. After completely wiping build/RelWithDebInfo and regenerating the build configuration it is working again 🤷‍♂️

digit-google added a commit to digit-google/ninja that referenced this issue Sep 2, 2024
The parser used asserts to verify the consistency of the
deps log, which resulted in crashes in production. Replace
them with correct checks and return conditions.

This allows the parser to survive and report corrupted
files, and Ninja to ignore the latter.

+ Add related unit-test.

Fixes ninja-build#2472
Fixes ninja-build#2309
digit-google added a commit to digit-google/ninja that referenced this issue Sep 3, 2024
The parser used asserts to verify the consistency of the
deps log, which resulted in crashes in production. Replace
them with correct checks and return conditions.

This allows the parser to survive and report corrupted
files, and Ninja to ignore the latter.

+ Add related unit-test.

Fixes ninja-build#2472
Fixes ninja-build#2309
digit-google added a commit to digit-google/ninja that referenced this issue Sep 4, 2024
The parser used asserts to verify the consistency of the
deps log, which resulted in crashes in production. Replace
them with correct checks and return conditions.

This allows the parser to survive and report corrupted
files, and Ninja to ignore the latter.

+ Add related unit-test.

Fixes ninja-build#2472
Fixes ninja-build#2309
@jhasse jhasse closed this as completed in 197dbdb Oct 4, 2024
@jhasse jhasse added this to the 1.13.0 milestone Oct 4, 2024
@ImmanuelHaffner
Copy link
Author

Hey @jhasse, do you know how much longer it will take you for the release of 1.13?
I am waiting for this patch. Could you release it sooner as a patch version of 1.12?

@jhasse
Copy link
Collaborator

jhasse commented Nov 7, 2024

1.13.0 will probably take quite a while (like a year or something). Doing 1.12.2 might be a good idea, I will think about it and see if I find the time.

@jhasse jhasse modified the milestones: 1.13.0, 1.12.2 Nov 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants