Skip to content
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

AbstractMethodError crash on Android #4161

Closed
ber4444 opened this issue Feb 8, 2022 · 8 comments · Fixed by #4221
Closed

AbstractMethodError crash on Android #4161

ber4444 opened this issue Feb 8, 2022 · 8 comments · Fixed by #4221
Labels
Bug Something isn't working

Comments

@ber4444
Copy link

ber4444 commented Feb 8, 2022

Describe the bug

java.lang.AbstractMethodError: abstract method "void io.opentelemetry.api.common.Attributes.forEach(j$.util.function.BiConsumer)"
at io.opentelemetry.exporter.zipkin.ZipkinSpanExporter.generateSpan(SourceFile:39)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at io.opentelemetry.exporter.zipkin.ZipkinSpanExporter.export(SourceFile:3)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at na.g0$c.export(SourceFile:1)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at na.j.export(SourceFile:10)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at na.s0.export(SourceFile:18)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at na.l0.export(SourceFile:15)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at io.opentelemetry.sdk.trace.export.BatchSpanProcessor$Worker.exportCurrentBatch(SourceFile:3)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at io.opentelemetry.sdk.trace.export.BatchSpanProcessor$Worker.run(SourceFile:8)
02-07 16:14:48.698 13877 13916 E AndroidRuntime:        at java.lang.Thread.run(Thread.java:919)

Steps to reproduce
Run sample Android app with the Splunk SDK that uses OpenTelemetry.

What did you expect to see?
No crash

What did you see instead?
Crashes as the Splunk SDK initializes.

What version and what artifacts are you using?
Artifacts: https://github.com/signalfx/splunk-otel-android
Version: com.splunk:splunk-otel-android:0.12.0, seems to be using opentelemetry 1.6.0
How did you reference these artifacts? (excerpt from your build.gradle, pom.xml, etc)

Environment
OS: Android 10
Only happens in release mode (proguard rules likely incomplete... what they shipped is https://github.com/signalfx/splunk-otel-android/blob/9d51a1feffb765a741463fb15d59555af354e2b6/splunk-otel-android/consumer-rules.pro)
We are using AGP 7.1.0 and minSdk = 23

@ber4444 ber4444 added the Bug Something isn't working label Feb 8, 2022
@jkwatson
Copy link
Contributor

jkwatson commented Feb 9, 2022

I believe there is a bug with desugaring with AGP 7.x. See this bug that I logged many months ago with the Android team: https://issuetracker.google.com/issues/202188674

Can you downgrade to AGP 4.1.2 and see if that fixes the issue?

@ber4444
Copy link
Author

ber4444 commented Feb 11, 2022

We cannot downgrade as we use jetpack compose and the issue you linked to is specific to API level 21 while we have minsdk 23.

@jkwatson
Copy link
Contributor

We cannot downgrade as we use jetpack compose and the issue you linked to is specific to API level 21 while we have minsdk 23.

I found that issue at API 21, but it also occurs at 23. This is definitely a real bug in the AGP that breaks core-library desugaring.

@ber4444
Copy link
Author

ber4444 commented Feb 18, 2022

This is working without desugaring as long as we run on API >= 26. (E.g. API 23 would crash with java.lang.NoClassDefFoundError: io.opentelemetry.api.common.a at io.opentelemetry.api.common.ArrayBackedAttributes.<clinit>(SourceFile:1), while API 24 would crash with java.lang.NoClassDefFoundError: Failed resolution of: Ljava/time/Duration).

@jkwatson
Copy link
Contributor

@ber4444 Please please please comment on that google ticket that I logged. We really need the Android team to fix this AGP bug, and they won't do it without people saying that they need it.

Why won't jetpack-compose work with a 4.x AGP version?

@laurit
Copy link
Contributor

laurit commented Feb 28, 2022

I believe the issue is that desugaring handles calls to Map.forEach(j.u.f.BiConsumer) by rewriting the call site, but it does not handle calling Attributes.forEach(j.u.f.BiConsumer) on an Attributes implementation that extends HashMap and inherits forEach from HashMap. We have 2 such implementations: AttributesMap and UnsafeAttributes in javaagent repo. I guess handling such construct is a bit too much for desugaring, it can't be handled by call site rewriting. To fix it I see two options, either don't extend HashMap and use an internal map or provide implementation for forEach.

@anuraaga
Copy link
Contributor

@laurit Thanks for the digging! Does implementing in the subclass just calling super work? That seems pretty simple

@laurit
Copy link
Contributor

laurit commented Feb 28, 2022

@anuraaga yes, just calling super works

  @Override
  public void forEach(BiConsumer<? super AttributeKey<?>, ? super Object> action) {
    super.forEach(action);
  }

gets transformed to

  public void forEach(j$.util.function.BiConsumer<? super io.opentelemetry.api.common.AttributeKey<?>, ? super java.lang.Object>);
    descriptor: (Lj$/util/function/BiConsumer;)V
    Code:
       0: aload_0
       1: aload_1
       2: invokestatic  #85                 // Method j$/util/Map$_CC.$default$forEach:(Ljava/util/Map;Lj$/util/function/BiConsumer;)V
       5: return

  public void forEach(java.util.function.BiConsumer);
    descriptor: (Ljava/util/function/BiConsumer;)V
    Code:
       0: aload_0
       1: aload_1
       2: invokestatic  #92                 // Method j$/util/function/BiConsumer$VivifiedWrapper.convert:(Ljava/util/function/BiConsumer;)Lj$/util/function/BiConsumer;
       5: invokevirtual #94                 // Method forEach:(Lj$/util/function/BiConsumer;)V
       8: return

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants