Consistent ninja crash when my build folder has a specific path #2309
Comments
|
Note that this needs |
|
Thank you for your archive. I wrote a small Python script to dump the content of your .ninja_deps file which shows that it is malformed! In particular, it contains multiple input path id values like 1441 that are out of bounds with respect of the max ids allocated in the file. This means two things:
It should be easy to fix the deps log loader against such input. On the other hand I do not understand how something like that could be produced. Maybe it's a bad recompaction, may |
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
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
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
|
Not sure if your team saw the updates, looks like this was similar to two other issues & that this is due to corrupted files in a specific path based on the commits below. Maybe there are no commit notifications? I noticed the other issues are still open also despite seeming to have resolutions. |
|
Nice, any write ups around best issues that need solving? I am interested in job opportunities at Google. |
|
I fear this is not the right place to ask for that. While some people at Google do work on Ninja from time to time, it is a now an open-source project maintained entirely externally on Github by many developers, from different companies and environments. For example the official maintainer (@jhasse) is not a Google employee. If you are interested in helping with Ninja, everybody will be happy for it, and you can take a look at the list of current issues in this Github repository. But be warned that this will not help you reach your stated goal (though a quick lookup with any search engine will give you the official page where you can find available positions). |
|
@digit-google I understand where you are coming from. I am not expecting anything from helping. I do know that it will be good for employees to verify that I can solve the technical issues in the day to day work via issues. I do also think it may help me connect with other engineers who find compiler engineering fun, interesting like yourself. |
|
@digit-google |
Hi,
I'm having a bewildering issue.. my build suddenly started failing, and only when i'm doing it in a specific path on my machine (I don't have any specific mounts or something funky like that... basic linux on an XFS partition).
it's an issue I sometimes see sporadically but just rm'ing the build folder is enough.. this time it's a persistent repro though.
If I build in any other path (even with the same final folder name) I don't see the issue. I thought there'd be some off-by-one name buffer issue or something like this somewhere which happens to trigger in just this exact case, but if I change even one character anywhere in the path, it seems to work so it does not look like a buffer overflow.
Trace:
I attach a core dump, my ninja binary and the source & build folder with their absolute paths:
repro.tar.gz
The text was updated successfully, but these errors were encountered: