D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368

mauriciogg · 2022-10-01T00:39:35Z

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

Error in bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/mirroring-sample-app/dexsplits/apk/9.shard.zip:org/chromium/base/MemoryPressureListener$$ExternalSyntheticLambda0.class.dex:
Attempt at compiling intermediate artifact without its context
Merge failed: Compilation failed to complete, origin: bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/mirroring-sample-app/dexsplits/apk/9.shard.zip:org/chromium/base/MemoryPressureListener$$ExternalSyntheticLambda0.class.dex
Exception in thread "main" com.android.tools.r8.CompilationFailedException: Merge failed: Compilation failed to complete, origin: bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/mirroring-sample-app/dexsplits/apk/9.shard.zip:org/chromium/base/MemoryPressureListener$$ExternalSyntheticLambda0.class.dex
at com.google.devtools.build.android.r8.DexFileMerger.main(DexFileMerger.java:389)
Target //apps/hermosa/hermosa-services/realtime/mirroring-sample-app:apk failed to build

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` returns `development 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:

nkoroste · 2022-10-03T18:40:28Z

@ahumesky

Bencodes · 2022-10-04T06:37:44Z

We are also seeing this in our repo using the latest rolling release (6.0.0-pre.20220922.1)

lukaciko · 2023-01-23T08:55:37Z

@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.

ahumesky · 2023-02-10T01:18:44Z

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 min_sdk_version attribute of android_binary (related: #10556 (comment)), or perhaps modified the hard coded dexing API level?

pswaminathan · 2023-02-23T16:42:33Z

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?

ahumesky · 2023-02-24T04:53:05Z

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.

ahumesky · 2023-03-02T21:29:19Z

After working through #16369 and talking with the D8 team, they propose (copied from #16369):

Update CompatDexBuilder to use the D8 DexFilePerClassFile consumer instead of DexIndexed (this should be a no op for the build as the current build there is already doing one dex per class file, but it uses another D8 API such that it can get the synthetic info).
Update the D8 DexFilePerClassFile accept function to also receive the "synthetic context" information if the compiled class is a compiler synthesized class.
Update CompatDexBuilder to write the synthetic context information to some build meta info for later access by the DexFileSplitter. Something like this is already done for the desugar dependencies which are written to a proto in META-INF/desugar_deps.
Update DexFileSplitter to use the meta-inf of synthetic classes to group with the right contexts.

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

ahumesky · 2023-06-28T00:12:48Z

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 <noreply@google.com>

ahumesky · 2023-06-30T01:33:25Z

There's still this same issue with the dex_shards attribute and DexMapper (which is still used for mobile-install "classic" while we open source the starlark replacement). I have an in progress change that applies same fix for DexFileSplitter to DexMapper, which we'll merge into Bazel 6.3 as well.

…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 <ben@ben.cm>

RELNOTES: None PiperOrigin-RevId: 547016404 Change-Id: I7a00a076db4a6d4f5e9e631357fc30696e6038f6

…16368

…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 <keerthanakumar@google.com> Co-authored-by: Ian (Hee) Cha <heec@google.com>

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

nkoroste · 2023-10-13T20:06:39Z

@ahumesky I think we're still seeing this issue on Linux only when filenames contain capital letters.

11:49:44 18:49:44 [Bazel] bazel-out/k8-opt-exec-ST-7a15de0b7d6a/bin/external/bazel_tools/tools/android/d8_dexmerger --input bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexsplits/apk/7.shard.zip --output bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexfiles/apk/7.shard.zip '--multidex=given_shard')
11:49:44 18:49:44 [Bazel] # Configuration: 064afe4bfa5b855024151ed67fa23ab997cd53f5f864cf3be12acef0225806a5
11:49:44 18:49:44 [Bazel] # Execution platform: @local_config_platform//:host
11:49:44 18:49:44 [Bazel] Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
11:49:44 18:49:44 [Bazel] Error in bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexsplits/apk/7.shard.zip:com/snap/ipc/buffers/IBufferMapper$-CC.class.dex:
11:49:44 18:49:44 [Bazel] Attempt at compiling intermediate artifact without its context
11:49:44 18:49:44 [Bazel] Merge failed: Compilation failed to complete, origin: bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexsplits/apk/7.shard.zip:com/snap/ipc/buffers/IBufferMapper$-CC.class.dex
11:49:44 18:49:44 [Bazel] Exception in thread "main" java.lang.RuntimeException: Merge failed: Compilation failed to complete, origin: bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexsplits/apk/7.shard.zip:com/snap/ipc/buffers/IBufferMapper$-CC.class.dex
11:49:44 18:49:44 [Bazel] at com.google.devtools.build.android.r8.DexFileMerger.main(DexFileMerger.java:412)
11:49:44 18:49:44 [Bazel] Caused by: com.android.tools.r8.CompilationFailedException: Compilation failed to complete, origin: bazel-out/k8-fastbuild/bin/apps/hermosa/hermosa-services/realtime/dexsplits/apk/7.shard.zip:com/snap/ipc/buffers/IBufferMapper$-CC.class.dex
11:49:44 18:49:44 [Bazel] at Version.fakeStackEntry(Version_8.1.51.java:0)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.M.a(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:5)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.utils.R0.a(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:81)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.utils.R0.a(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:32)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.utils.R0.a(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:31)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.utils.R0.b(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:2)
11:49:44 18:49:44 [Bazel] at com.android.tools.r8.D8.run(R8_8.1.51_9b737621870a00577be8badac89ea7485627e0cae5c007fd3c57c275c1a604a9:6)
11:49:44 18:49:44 [Bazel] at com.google.devtools.build.android.r8.DexFileMerger.run(DexFileMerger.java:395)
11:49:44 18:49:44 [Bazel] at com.google.devtools.build.android.r8.DexFileMerger.main(DexFileMerger.java:409)
11:49:44 18:49:44 [Bazel] Caused by: com.android.tools.r8.utils.b: Attempt at compiling intermediate artifact without its context

ricowind · 2023-10-17T06:25:01Z

nkoroste@ is this a custom R8 build (I can't retrace)?

Is IBufferMapper.class in any of the shards?

mauriciogg mentioned this issue Oct 1, 2022

Guarantee classes are packed with their inner synthetic lambdas during sharding #16369

Closed

sgowroji added team-Android Issues for Android team untriaged type: bug labels Oct 1, 2022

ahumesky added P1 I'll work on this now. (Assignee required) and removed untriaged labels Oct 25, 2022

copybara-service bot closed this as completed in 9092303 Jun 28, 2023

ahumesky mentioned this issue Jun 29, 2023

Cherrypick fixes for #16368 into Bazel 6.3.0 #18808

Merged

ahumesky reopened this Jun 30, 2023

copybara-service bot closed this as completed in 3e800a7 Jul 6, 2023

ahumesky mentioned this issue Jul 6, 2023

Cherrypick Dexmapper fixes into Bazel 6.3.0 #18852

Closed

ahumesky mentioned this issue Jul 6, 2023

[6.3.0] Teach DexMapper to not separate synthetic classes from their context … #18853

Merged

copybara-service bot pushed a commit that referenced this issue Jul 10, 2023

Update Android tools to 0.29.0 for fixes to DexMapper for #16368

37ceec5

RELNOTES: None PiperOrigin-RevId: 547016404 Change-Id: I7a00a076db4a6d4f5e9e631357fc30696e6038f6

ahumesky added a commit to ahumesky/bazel that referenced this issue Jul 11, 2023

Update Android tools to 0.27.1 for fixes to DexMapper for bazelbuild#…

09726fa

…16368

ahumesky mentioned this issue Jul 11, 2023

[6.3.0] Update Android tools to 0.27.2 for fixes to DexMapper for https://gith... #18891

Merged

brettchabot added a commit to android/android-test that referenced this issue Aug 18, 2023

Update to bazel 6.3

e430b00

The main motivation is to pick up fix for bazelbuild/bazel#16368, which appears to be needed to increment version of androidx.window.

brettchabot added a commit to android/android-test that referenced this issue Aug 18, 2023

iUpdate to bazel 6.3

94802d8

The main motivation is to pick up fix for bazelbuild/bazel#16368, which appears to be needed to increment version of androidx.window.

brettchabot mentioned this issue Aug 18, 2023

Update to bazel 6.3 android/android-test#1892

Merged

ricowind mentioned this issue Oct 17, 2023

Conflicting version of R8/D8 in Dexer/Desugar classpath #19831

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368

D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368

mauriciogg commented Oct 1, 2022 •

edited

Loading

nkoroste commented Oct 3, 2022

Bencodes commented Oct 4, 2022 •

edited

Loading

lukaciko commented Jan 23, 2023

ahumesky commented Feb 10, 2023

pswaminathan commented Feb 23, 2023

ahumesky commented Feb 24, 2023

ahumesky commented Mar 2, 2023

ahumesky commented Jun 28, 2023

ahumesky commented Jun 30, 2023

nkoroste commented Oct 13, 2023 •

edited

Loading

ricowind commented Oct 17, 2023

D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368

D8 dex merger fails when a synthetic class is placed on a different shard than its container class #16368

Comments

mauriciogg commented Oct 1, 2022 • edited Loading

Description of the bug:

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Which operating system are you running Bazel on?

What is the output of bazel info release?

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

Have you found anything relevant by searching the web?

Any other information, logs, or outputs that you want to share?

nkoroste commented Oct 3, 2022

Bencodes commented Oct 4, 2022 • edited Loading

lukaciko commented Jan 23, 2023

ahumesky commented Feb 10, 2023

pswaminathan commented Feb 23, 2023

ahumesky commented Feb 24, 2023

ahumesky commented Mar 2, 2023

ahumesky commented Jun 28, 2023

ahumesky commented Jun 30, 2023

nkoroste commented Oct 13, 2023 • edited Loading

ricowind commented Oct 17, 2023

mauriciogg commented Oct 1, 2022 •

edited

Loading

What is the output of `bazel info release`?

If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?

Bencodes commented Oct 4, 2022 •

edited

Loading

nkoroste commented Oct 13, 2023 •

edited

Loading