Different Behavior Between Programs packed by R8 and D8 [354625682]

Verified

Bug

Status Update

No update yet.

Description

qi...@gmail.com

created issue #1

Jul 22, 2024 09:56AM

Versions

r8 version: R8 main (build engineering)
art version: ART version 2.1.0 x86_64
java version: 17.0.10

Description

When processing jar files to generate dex files using D8 and R8 respectively, the resulting dex files behave inconsistently during execution. The dex file generated by R8 crashes upon execution with the error "Exception in thread 'main' java.lang.NullPointerException," which should actually be caught. In contrast, the dex file generated by D8 executes normally. We suspect this is an issue with R8.

Step to Reproduce

javac -source 8 -target 8 -cp . Test.java
jar cvf classes.jar ./*.class
java -cp r8.jar com.android.tools.r8.R8 --pg-conf rules.pro --release --output ./ ./classes.jar
env ANDROID_LOG_TAGS=*:f ANDROID_DATA=./ /path/to/art --64 --no-compile -cp ./classes.dex Test > result

Expected Result(d8 dex output)

over

Actual Result(r8 dex output)

Exception in thread "main" java.lang.NullPointerException
	at Test.main(SourceFile:11)

Testcase Source Code

import java.net.SocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.DatagramChannel;
class Test {
  void a(String[] b) {
    ByteBuffer byteBuffer= null;
    SocketAddress socketAddress = null;
    DatagramChannel datagramChannel = null;
    try {
      if (socketAddress == null)
        datagramChannel.receive(byteBuffer);
    } catch (Throwable $) {
    }
  }
  public static void main(String[] c) {
    Test e = new Test();
    e.a(c);
    System.out.println("over");
  }
}

rules.pro

-injars classes.jar
-libraryjars android.jar
-keep class Test { public main(java.lang.String[]); }

classes.dex

636 B

Download

classes.jar

958 B

Download

Comments

cl...@google.com <cl...@google.com> Jul 22, 2024 12:07PM

Reassigned to cl...@google.com.

cl...@google.com <cl...@google.com> #2Jul 29, 2024 08:38AM

deleted

ap...@google.com <ap...@google.com> #3Jul 29, 2024 08:58AM

(reposting under work account)

We have been hitting this issue constantly. Is it possible to configure those tasks to be non cacheable as a workaround or is that only possible inside of AGP?

ap...@google.com <ap...@google.com> #4Jul 29, 2024 08:58AM

Currently the only way to disable caching for dexing transforms is to patch AGP manually by providing a patched DexTransform.kt file in buildSrc. Please see https://issuetracker.google.com/169266011#comment27, section on "Workarounds" for an example.

ap...@google.com <ap...@google.com> #5Jul 30, 2024 11:19AM

Thanks. Ignoring potential build perf impacts, if we essentially commented out the processIncrementally block in DexingTransform.kt and always ran non-incrementally, would that workaround this issue?

ap...@google.com <ap...@google.com> #6Jul 30, 2024 11:19AM

Yes, always run the dex transform non-incrementally is another workaround.

ap...@google.com <ap...@google.com> #7Jul 30, 2024 11:19AM

Is it possible to do same patch with included build?

cl...@google.com <cl...@google.com> Jul 30, 2024 12:06PM

Verified by cl...@google.com.

ap...@google.com <ap...@google.com> #8Jul 30, 2024 12:07PM

I guess so, could you give it a try?

ap...@google.com <ap...@google.com> #9Jul 30, 2024 12:07PM

I've tried(not very neat) but it only work with buildSrc

Anyway, what about issue, I've tried a lot of attempts to fix and helped only turn off jacoco transformation `useJacocoTransformInstrumentation = false`.

What was changed in agp 7.4.x from 7.3.1 that break this?

ap...@google.com <ap...@google.com> #10Jul 30, 2024 12:07PM

Are you referring to https://issuetracker.google.com/266109833#comment2? That issue is different from this issue.

(Regarding What was changed in agp 7.4.x from 7.3.1 that break this?: I don't know, my theory is that some of your code has changed too when updating AGP, which exposed the Jacoco bug. Please post your comments in that issue if you'd like to continue discussing this.)

an...@google.com <an...@google.com> #11Aug 6, 2024 10:15PM

Edit: we were actually not applying the patch correctly, so this was user error.

We've been running with a patched version of DexingTransformer.kt for about a week but are still seeing the issue. First I tried commenting out @CacheableTransform on DexingNoClasspathTransform, but after devs were still experiencing the error, I tried reverting that change and instead applying what I'd suggested in comment #5, but we're still running into the issue.

Is there any other workaround or additional information I can provide to help debug? At first I thought it's perhaps the patched version of DexingTransformer.kt wasn't being picked up, but I confirmed that it was by throwing an exception inside of doTransform.

an...@google.com <an...@google.com> #12Aug 9, 2024 12:55AM

Regarding the non-cacheable fix: Can you check if it actually takes effect (i.e., the transform outputs are not cached)? Maybe comment out @CacheableTransform in the BaseDexingTransform class too?

Regarding the non-incremental fix: Note that the stacktrace in comment #1 is:

at com.android.build.gradle.internal.dependency.BaseDexingTransform.processIncrementally(DexingTransform.kt:227)
at com.android.build.gradle.internal.dependency.BaseDexingTransform.doTransform(DexingTransform.kt:137)

Please check your stacktrace after applying the non-incremental fix:

If it still shows processIncrementally, that means the fix was not applied successfully.
If it shows processNonIncrementally, that is probably a different bug.

Issue 354625682

Description

Versions

Description

Step to Reproduce

Expected Result(d8 dex output)

Actual Result(r8 dex output)

Testcase Source Code

Issue summary

Comments

cl...@google.com <cl...@google.com> Jul 22, 2024 12:07PM

cl...@google.com <cl...@google.com> #2Jul 29, 2024 08:38AM

ap...@google.com <ap...@google.com> #3Jul 29, 2024 08:58AM

ap...@google.com <ap...@google.com> #4Jul 29, 2024 08:58AM

ap...@google.com <ap...@google.com> #5Jul 30, 2024 11:19AM

ap...@google.com <ap...@google.com> #6Jul 30, 2024 11:19AM

ap...@google.com <ap...@google.com> #7Jul 30, 2024 11:19AM

cl...@google.com <cl...@google.com> Jul 30, 2024 12:06PM

ap...@google.com <ap...@google.com> #8Jul 30, 2024 12:07PM

ap...@google.com <ap...@google.com> #9Jul 30, 2024 12:07PM

ap...@google.com <ap...@google.com> #10Jul 30, 2024 12:07PM

an...@google.com <an...@google.com> #11Aug 6, 2024 10:15PM

an...@google.com <an...@google.com> #12Aug 9, 2024 12:55AM

Add comment

Issue metadata