[Android] SIGSEGV null pointer dereference in globalEnv_CallVoidMethod (libdartjni.so)

[dfdgsdfg]

Description

App crashes with a native SIGSEGV (null pointer dereference) on Android in release mode. The crash originates from globalEnv_CallVoidMethod in libdartjni.so, which calls CallVoidMethodV with a null _jobject*.

We suspect this is related to Session Replay capturing screen state, as the Dart VM frames show a repeated iterative pattern consistent with widget tree traversal.

Environment

• Flutter: 3.38.9 (stable)
• Dart: 3.10.8
• datadog_flutter_plugin: 3.0.1
• datadog_session_replay: 1.0.0-preview.9
• datadog_tracking_http_client: 3.0.1
• datadog_dio: 2.0.0
• datadog_inappwebview_tracking: 2.0.0
• jni (transitive): 0.14.2
• Android NDK: 28.2.13676358
• R8/ProGuard: Disabled (minifyEnabled is false)
• Device arch: arm64-v8a

Setup

Session Replay is enabled and wraps the entire app widget tree via SessionReplayCapture:

DatadogConfiguration(
  // ...
  nativeCrashReportEnabled: true,
  rumConfiguration: DatadogRumConfiguration(applicationId: applicationId),
  site: DatadogSite.us5,
)..enableSessionReplay(
  DatadogSessionReplayConfiguration(
    textAndInputPrivacyLevel: TextAndInputPrivacyLevel.maskSensitiveInputs,
    touchPrivacyLevel: TouchPrivacyLevel.show,
    replaySampleRate: replaySampleRate,
  ),
);

Debug mode already skips Datadog initialization entirely (to avoid the hot-restart JNI crash from #932).

Tombstone (symbolicated)

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
Cause: null pointer dereference

#00 pc 0x3150bc  art::JValue art::InvokeVirtualOrInterfaceWithVarArgs<_jmethodID*>(
                   art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, std::__va_list)
                   [libart.so]
#01 pc 0x620a84  art::JNI<false>::CallVoidMethodV(_JNIEnv*, _jobject*, _jmethodID*, std::__va_list)
                   [libart.so]
#02 pc 0x10650   globalEnv_CallVoidMethod
                   [libdartjni.so]
#03 pc 0x7d1b34  dlc.vmcode
#04 pc 0xae07ec  dlc.vmcode
#05 pc 0xaeb420  dlc.vmcode
#06 pc 0xaeb354  dlc.vmcode
#07 pc 0xaeb1b0  dlc.vmcode
#08 pc 0xaeac98  dlc.vmcode
#09 pc 0xae96f0  dlc.vmcode
#10 pc 0xad8d24  dlc.vmcode
#11 pc 0xae9644  dlc.vmcode
#12 pc 0xad8984  dlc.vmcode
#13 pc 0x11f7584 dlc.vmcode
#14 pc 0x801260  dlc.vmcode
#15 pc 0x8010e4  dlc.vmcode
#16 pc 0x7fe2e8  dlc.vmcode
#17 pc 0x7ff904  dlc.vmcode
#18 pc 0x11f7980 dlc.vmcode
#19 pc 0xaf765c  dlc.vmcode
#20 pc 0x11f7584 dlc.vmcode
#21 pc 0x801260  dlc.vmcode
#22 pc 0x8010e4  dlc.vmcode
#23 pc 0x7fe2e8  dlc.vmcode
#24 pc 0x7ff904  dlc.vmcode
#25 pc 0x11f7aac dlc.vmcode
#26 pc 0x818104  dlc.vmcode
#27 pc 0x11f7584 dlc.vmcode
#28 pc 0x11f8474 dlc.vmcode
#29 pc 0x7e1690  dlc.vmcode
#30 pc 0x7e1584  dlc.vmcode
#31 pc 0x7e1548  dlc.vmcode
#32 pc 0x7d426c  dlc.vmcode
#33 pc 0xe6d7fc  libflutter.so
#34 pc 0xdb3df8  libflutter.so
#35 pc 0xcfd3d0  libflutter.so
#36 pc 0xe716b4  libflutter.so
#37 pc 0xe9dcc4  libflutter.so
#38–#49           libflutter.so / libutils.so

Analysis

• The null is in the _jobject* parameter — the Java object being called on is null
• The repeated dlc.vmcode frame pattern (frames 📝 Minor language / spelling fixes to CONTRIBUTING #14–Initial support for manual RUM #17 ≈ 💥 Change Datadog() to Datadog.instance #21–Adding logging and error handling #24) suggests an iterative traversal, possibly Session Replay walking the widget tree
• This is not the hot-restart issue from [Android] Hot restart crash: "Callback invoked after it has been deleted" in PortProxyBuilder (v3.0.0) #932 — that was SIGABRT with "Callback invoked after it has been deleted". This is a SIGSEGV null pointer in release mode at runtime
• ProGuard/R8 is disabled, so class stripping is not the cause

Related

• [Android] Hot restart crash: "Callback invoked after it has been deleted" in PortProxyBuilder (v3.0.0) #932 — Hot restart JNI callback crash (fixed in 3.0.1 / preview.9 via singleton bridge)
• ClassNotFoundException for DatadogLogEventMapper$EventMapper in release builds #936 — ClassNotFoundException for DatadogLogEventMapper (ProGuard-related, also fixed)

[fuzzybinary]

Hi @dfdgsdfg,

Thanks for reporting, and sorry for the inconvenience!

Any chance you have any STR, or is it fairly random? The only JNI methods we call during tree capture should be telemetryError, telemetryDebug and saveImageForProcessing.

This appears to be a disconnect between Dart thinking it has a strong pointer to a JObject, and JNI thinking otherwise. I wonder if this happens immediately after a GC, and if are accidentally holding something weak... However, I can't reproduce it in simple cases.

Do you have anything strange about your setup? Are you trying to run capture from multiple Flutter Engines or from multiple isolates, for example? Does this appear to happen after a specific event or on a particular screen, or with a particular image?

Also, did preview.9 not fix the hot restart issue for you?

[dfdgsdfg]

Additional crash data from production (v3.26.2, datadog_flutter_plugin 3.0.1, datadog_session_replay 1.0.0-preview.9)

We're seeing multiple Datadog Session Replay-related crashes in production on Android. Here's the data from Firebase Crashlytics:

1. JNI OOM in FlutterSessionReplayBridge.setHasReplay (confirms Session Replay as crash source)

Full stack trace:

java.lang.reflect.UndeclaredThrowableException
  at $Proxy5.onContextChanged
  at com.datadoghq.flutter.sessionreplay.FlutterSessionReplayBridge.enable$lambda$1 (FlutterSessionReplayBridge.kt:57)
  at com.datadoghq.flutter.sessionreplay.feature.DefaultFlutterSessionReplayFeature.onContextUpdate$lambda$0 (FlutterSessionReplayFeature.kt:98)
  at android.os.Handler.handleCallback (Handler.java:995)
  ...

Caused by: com.github.dart_lang.jni.PortProxyBuilder$DartException:
  java.lang.OutOfMemoryError: Failed to allocate a 64 byte allocation with 2569760 free bytes
  and 2509KB until OOM, target footprint 268435456, growth limit 268435456

  at DatadogCore.updateFeatureContext
  at DefaultFlutterSessionReplayFeature.setHasReplay
  at FlutterSessionReplayBridge.setHasReplay
  at com.github.dart_lang.jni.PortProxyBuilder._invoke (Native Method)

• Device: Samsung Galaxy S25 Ultra (SM-S938N), Android 16, ARM64
• Process state: BACKGROUND
• Heap: <1% free after GC (only 2.5MB remaining)
• Logs before crash: StopVideoPlayerCommand called ~100 times in rapid succession (likely a feed scroll), then OOM during Session Replay context update

2. [dlc.vmcode] SIGABRT during Datadog initialization (21 events, 12 users)

• Native SIGABRT with no symbolicated frames (blame frame: dlc.vmcode)
• Crashes during Datadog init — last log entry is datadog> analyticsConfig:... with replaySampleRate: 1.0, app never reaches app scope push
• Device: Samsung Galaxy S9+ (SM-G965N), Android 8.0, 405MB free RAM
• This crash pattern is consistent with Session Replay native code crashing and corrupting the Activity lifecycle

3. Additional Datadog OOM crashes (1 event each, all new in 1.0.0-preview.9)

• DatadogRumMonitor.eventDropped → java.lang.OutOfMemoryError
• DatadogCore.getFeatureContext → java.lang.OutOfMemoryError

Suspected downstream impact

We also see PlatformException(NO_ACTIVITY, The current activity is null) as the #1 crash (157 events, 147 users) on 1.0.0-preview.9. We suspect the dlc.vmcode SIGABRT during Datadog init may corrupt/destroy the Activity reference, causing subsequent platform channel calls to fail with NO_ACTIVITY. Both crash patterns show:

• notification_receive event before cold start
• replaySampleRate > 0 (Session Replay active)
• Unusual MainActivity → LicenseActivity screen_view sequence

Environment

• Flutter: 3.38.9 (stable)
• datadog_flutter_plugin: 3.0.1
• datadog_session_replay: 1.0.0-preview.9
• App: Android, release mode
• Affected devices: Various Samsung models (S9+, S25 Ultra, Note9), Android 8–16

[fuzzybinary]

Hi @dfdgsdfg ,

SIGABRT should causes a tombstone, so execution of the app won't continue if it's received, so there shouldn't be a "corrupted" Activity reference. The app is forcibly terminated in this case, so it is very unlikely the PlatformException NO_ACTIVITY crash is related to any SIGABRT signal.

I'm still going to need more information to try to diagnose both issues. The crash on launch is particularly concerning. Are there any usage patterns to either crash? Is the crash on launch potentially caused by a push notifications?

Also, I see you have a MainActivity -> LicenseActivity as part of your lifecycle.... are you running a Hybrid mobile application? If so, are you trying to capture both native and Flutter in Session Replay? This unfortunately is not supported and might cause a crash.

Regarding numbers 1 and 3, I will say that if this is on us, I take it very seriously, but unless Datadog or Session Replay is leaking (which we don't have any evidence of), I'm not sure what we can do about the OOM errors. It's not that we're allocating a lot of memory, it's that the memory currently available is incredibly fragmented, and we happen to want to allocate in this state.

I would see if there's a memory allocation pattern in your application that might be causing OOMs. Given there was <1% of heap memory available after a GC, there's likely a memory leak somewhere. Unless you're seeing Datadog leaking or allocating a significant amount of memory, your problem is probably elsewhere and Datadog's failure to allocate memory is just a symptom of a larger problem.

One possibility, though, given the example scenario you provided, is that we're trying to capture a significant number of images quickly. Since Flutter Session Replay has to copy these images for processing, trying to process a large number of them could cause an issue. One potential workaround would be to mask non-asset images. This will prevent you from seeing downloaded images in Session Replay, but might tell us if this is the causes of the excessive memory usage.

If that appears to be the case, we can look into adding a hard limit on the number of images captured, as well as adding a configurable max size to images captured during SR.

[dfdgsdfg]

@fuzzybinary

Thank you for the analysis. I agree with many of the points you raised. Although Session Replay is not yet GA, I believe these results could be caused by other issues. I will investigate further and report back if any additional feedback or clarification is needed.