-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368
Comments
We are also seeing this in our repo using the latest rolling release (6.0.0-pre.20220922.1) |
@ahumesky can this issue be added to Bazel 6.1. release blockers? As you noted #16369 does not completely solve it. We are hesitant to upgrade to 6.0 even with that fix since we might run into the same issue with another of synthetic classes at any point. |
Yes I think we can get the fix in for 6.1. But a question for those of you running into this issue -- we're not seeing this internally, so I'm trying to figure out what differences might be causing this with bazel. Is anyone using the |
We are not setting either of those. We are setting min API level in the manifest using the uses-sdk tag. For an application that exhibits it, it is happening consistently. However, triggering it doesn't seem to be related to changing build rules. i.e. We have experienced with an application in which the change that triggered this behavior is purely a code change. It's a little hard for me to create a repro, given that it depends on internal code. Also—I don't see this added to 6.1 release blockers. Is that still a possibility? |
Thanks -- turns out the reason we weren't seeing this internally isn't related to API level exactly, but internally we have other code paths that avoid this problem. We're removing these codepath soon so that the code matches internally and externally, so we'll want the fix for this as well. It's been pretty tricky to get the fix for this working in all cases, and has required reworking the PR for this a fair bit (#16369 (comment)). I'm rerunning all our tests again to see if anything still fails with the updates to the PR, so I'm a little hesitant now to block 6.1.0 on this if there are more cases that need to be addressed. If we can't get the fix in for 6.1.0 we cherrypick this into 6.2.0. |
After working through #16369 and talking with the D8 team, they propose (copied from #16369):
The D8 team would handle 1 and 2, and the bazel team and/or community could do 3 and 4. This avoids coupling to D8 implementation details and having to parse dex files and hopefully reduces the code complexity a bit. |
This completes steps 2 and 3 in b/241351268#comment9 towards resolving #16368 PiperOrigin-RevId: 530238344 Change-Id: I569bf8e3bfa81f7005f3e9b79338d5a5b868e339
This completes steps 2 and 3 in b/241351268#comment9 towards resolving bazelbuild#16368 PiperOrigin-RevId: 530238344 Change-Id: I569bf8e3bfa81f7005f3e9b79338d5a5b868e339
The fix for this should be ready to submit tomorrow, and then I'll cherrypick it into the Bazel 6.3 release. |
This completes steps 2 and 3 in b/241351268#comment9 towards resolving bazelbuild#16368 PiperOrigin-RevId: 530238344 Change-Id: I569bf8e3bfa81f7005f3e9b79338d5a5b868e339
… so that synthetic classes don't end up without their context classes in dex shards, which will causing merging to fail in DexFileMerger. Fixes bazelbuild#16368. RELNOTES: None PiperOrigin-RevId: 544134712 Change-Id: Ib29f6659f18dd71be96a7985bc25cfb44e719ae5
* Update D8/R8 dependency in bazel to 8.0.40 PiperOrigin-RevId: 520331100 Change-Id: Ia150c637747c980fc5cdfa07c80edd3a9e30e04b * Add options converters specific to R8 to avoid depending on android_builder_lib which causes classpath conflicts with D8 classes. RELNOTE: None PiperOrigin-RevId: 526149555 Change-Id: Iacfce24cc3d2327ef63c47f3bfd76813beaefc7a * Add android_gmaven_r8 to bazel's WORKSPACE file so that it overrides the version of R8 that might come from android_remote_tools.WORKSPACE in a released version of bazel used to run the test (which would be potentially out of date with respect to the source code). Also merge this with android_gmaven_r8_for_testing since they would be redundant. RELNOTES: None. PiperOrigin-RevId: 529830525 Change-Id: Ic5c18ce5beb7fb915b084dc19590a05b04675548 * Collect the contexts of D8 compiler-synthesized classes. This completes steps 2 and 3 in b/241351268#comment9 towards resolving #16368 PiperOrigin-RevId: 530238344 Change-Id: I569bf8e3bfa81f7005f3e9b79338d5a5b868e339 * Group synthetic classes with their context classes in DexFileSplitter so that synthetic classes don't end up without their context classes in dex shards, which will causing merging to fail in DexFileMerger. Fixes #16368. RELNOTES: None PiperOrigin-RevId: 544134712 Change-Id: Ib29f6659f18dd71be96a7985bc25cfb44e719ae5 --------- Co-authored-by: Googler <[email protected]>
There's still this same issue with the |
…classes when sharding dexes, like DexFileSplitter in bazelbuild@9092303. Fixes bazelbuild#16368 RELNOTES: None PiperOrigin-RevId: 546041575 Change-Id: I12fa8cff15b13534ca9a5682b7e9b43e6c860ef8
…classes when sharding dexes, like DexFileSplitter in bazelbuild@9092303. Fixes bazelbuild#16368 RELNOTES: None PiperOrigin-RevId: 546041575 Change-Id: I12fa8cff15b13534ca9a5682b7e9b43e6c860ef8
…context … (#18853) * Teach DexMapper to not separate synthetic classes from their context classes when sharding dexes, like DexFileSplitter in 9092303. Fixes #16368 RELNOTES: None PiperOrigin-RevId: 546041575 Change-Id: I12fa8cff15b13534ca9a5682b7e9b43e6c860ef8 * Use remap_paths to android_tools This ensures that the `all_android_tools_deploy.jar` and `ImportDepsChecker_deploy.jar` artifacts end up in the root of the `tar` where `exports_files` is able to reference them. Before this PR the tar had the following directory structure: ``` ./ ./BUILD ./WORKSPACE ./desugar_jdk_libs.jar ./version.txt ./src/java_tools/import_deps_checker/java/com/google/devtools/build/importdeps/ImportDepsChecker_deploy.jar ./src/tools/android/java/com/google/devtools/build/android/all_android_tools_deploy.jar ``` After: ``` BUILD ImportDepsChecker_deploy.jar WORKSPACE all_android_tools_deploy.jar desugar_jdk_libs.jar version.txt ``` Closes #17187. PiperOrigin-RevId: 501862387 Change-Id: Ida51fa3f0bd3b07d3106653e5292a90cac143b68 * Add rules_pkg to the list of test repositories set up for shell integration tests. Commit b7a79ff depends on this. This is a partial cherrypick of e9929af. --------- Co-authored-by: Benjamin Lee <[email protected]>
RELNOTES: None PiperOrigin-RevId: 547016404 Change-Id: I7a00a076db4a6d4f5e9e631357fc30696e6038f6
…ps://gith... (#18891) * Update Android tools to 0.27.1 for fixes to DexMapper for #16368 * Update Android rules to 0.27.2 to include #18909 --------- Co-authored-by: keertk <[email protected]> Co-authored-by: Ian (Hee) Cha <[email protected]>
The main motivation is to pick up fix for bazelbuild/bazel#16368, which appears to be needed to increment version of androidx.window.
The main motivation is to pick up fix for bazelbuild/bazel#16368, which appears to be needed to increment version of androidx.window.
… so that synthetic classes don't end up without their context classes in dex shards, which will causing merging to fail in DexFileMerger. Fixes bazelbuild#16368. RELNOTES: None PiperOrigin-RevId: 544134712 Change-Id: Ib29f6659f18dd71be96a7985bc25cfb44e719ae5
@ahumesky I think we're still seeing this issue on Linux only when filenames contain capital letters.
|
nkoroste@ is this a custom R8 build (I can't retrace)? Is IBufferMapper.class in any of the shards? |
Description of the bug:
a desugared lambda is packed in a different shard than the one
from its original class D8 will fail with the following message:
Attempt at compiling intermediate artifact without its context
e.g.
I'm encountering an issue when compiling my app with the following classes:
org/chromium/base/MemoryPressureListener ``org/chromium/base/MemoryPressureListener$$ExternalSyntheticLambda0
bazel fails with the following message
Here the container class is in shard #8 and the lambda class is in shard #9
Running with d8 dexmerger and native multidex.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Its hard to provide a small reproducible example since it needs to be an app large enough to exceed the size of a dex file and the sharding has to result in a lambda class ending up in a different shard than the container class.
Which operating system are you running Bazel on?
Linux/Mac
What is the output of
bazel info release
?Internal build merged with master at commit b6803a2
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: