Fix ijar failing on empty jars. #12893
Conversation
The problem happens when all the files are filtered out. In such case a dummy file is created, but not accounted for in the size estimation. Fixes bazelbuild#10162
third_party/ijar/ijar.cc
Outdated
| in->CalculateOutputLength() + | ||
| EstimateManifestOutputSize(target_label, injecting_rule_kind); | ||
| u8 output_length = in->CalculateOutputLength(); | ||
| if (output_length < 103ull + DUMMY_PATH_LENGTH) { |
There was a problem hiding this comment.
From measurement, error message tells 108 bytes are needed. "dummy" appears twice in the output, so 98+2*strlen("dummy") should work even if somebody changes "dummy". (I fixed 103).
Somehow I cannot get the same number by adding together numbers used EstimateManifestOutputSize. And I consider reverse engineering zip code and figuring out header sizes a bit too much effort for this fix.
| @@ -368,9 +370,12 @@ static void OpenFilesAndProcessJar(const char *file_out, const char *file_in, | |||
| strerror(errno)); | |||
| abort(); | |||
| } | |||
| u8 output_length = | |||
| in->CalculateOutputLength() + | |||
There was a problem hiding this comment.
I wonder of CalculateOutputLength should be handling this instead of fixing up the size later?
There was a problem hiding this comment.
Consider adding a test?
Done
I also commented in the bug--it's not clear if this is something that happened in a real build, it should be rare to see completely empty jar files that don't even contain a manifest.
True that.
There was a problem hiding this comment.
CalculateOutputLength is part of zip.cc and has no knowledge that we're adding dummy file.
The problem happened when all the files are filtered out. In such case a dummy file is created, but it was not accounted for in the size estimation.
Fixes #10162