Skip to content

RangeError: Maximum call stack size exceeded from console instrumentation (SDK-CRASHES-REACT-NATIVE-5HZ) #6420

Description

@antonis

Summary

We're seeing a RangeError: Maximum call stack size exceeded originating in @sentry/core's console instrumentation on React Native. Internal SDK-crash issue: SDK-CRASHES-REACT-NATIVE-5HZ (408 occurrences, 8 users; first seen 2026-01-06, still ongoing). Observed on @sentry/core@10.61.0, RN SDK release 8.16.0, iOS.

Stack trace (abbreviated)

RangeError
  ...
  @sentry/core/build/esm/instrument/console.js:43 (<anonymous>)   ← repeated ~40x
  @sentry/core/build/esm/instrument/console.js:40 (<anonymous>)
  @sentry/core/build/esm/instrument/handlers.js:44 (triggerHandlers)
  @sentry/core/build/esm/utils/debug-logger.js:52 (error)
  @sentry/core/build/esm/utils/debug-logger.js:55 (_maybeLog)

Root cause

@sentry/core's console wrapper reads its "original" method dynamically from the module-scoped originalConsoleMethods[level] on every call. If instrumentConsole() wraps the console more than once within the same copy of @sentry/core, the second pass stores our own wrapper into originalConsoleMethods[level]. From then on, calling through to the "original" (directly, and via consoleSandbox in the debug logger — hence the _maybeLog entry point) re-enters the wrapper indefinitely → stack overflow.

Fix (core side)

A defensive fix that makes instrumentConsole() idempotent per SDK copy (each copy wraps each console level at most once) has been opened in sentry-javascript:

Once released, bumping the @sentry/core dependency in this SDK will resolve the crash.

Action items for sentry-react-native

  • Pick up the @sentry/core release containing fix(core): Prevent infinite recursion when console is instrumented twice sentry-javascript#21959 (dependency bump).
  • Investigate the RN-specific trigger: what causes @sentry/core's console instrumentation to run more than once against the same module state? Likely candidates are instrumentation/module state being re-initialized (e.g. on reload) while the global console stays wrapped, or bundler-duplicated @sentry/core copies. Understanding this would confirm whether the defensive core fix is sufficient or whether there's an RN-side lifecycle issue to address.

Filed from investigation on the core-side fix (getsentry/sentry-javascript#21959).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions