Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Memory grows every time the same AudioBuffer is assigned to a new source node (iOS)

Aperta
  • Qualcosa non va?
#1,340 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
ios, react-native
Ambito
mobile-dev, performance

Direzione di ricerca

Start with the linked repro and run its “Run” flow to compare HermesInternal.getInstrumentedStats().js_externalBytes with the raw PCM size after decoding and each src.buffer = buf assignment. Read related issue #1263 and PR #1283 for prior Android investigation and ownership context. Done means repeated assignments of the same buffer no longer add a full buffer’s worth of external memory, retained accounting returns to the decoded buffer, and the stress run does not grow toward an OOM.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Description

On iOS with Hermes, the external memory reported to the JS engine for decoded audio is much larger than the audio itself, and it grows with every AudioBufferSourceNode that is given the same AudioBuffer:

  • decodeAudioData raises HermesInternal.getInstrumentedStats().js_externalBytes by 2x the raw float32 PCM size of the decoded buffer.
  • Every source.buffer = buf assignment raises it by another 2x of the raw PCM size, even though it is the same buffer each time.
  • After all references are dropped, 4x of the raw PCM size stays reported (no globalThis.gc in this build; still there 5 seconds later).

For a 131 s stereo 48 kHz input (raw PCM 47.97 MiB), one decode plus six source nodes sharing that buffer report 671.6 MiB of external memory, 14x the PCM size.

A player that creates a new source node on every play, seek or chunk change, which as far as I know is the usual pattern since a source can only be started once, reaches Hermes' limit quickly. In our app a randomized play/pause/seek stress run ends in a Hermes out-of-memory abort after about 3.5 minutes on 0.13.6, with js_externalBytes at about 3.4 GB and the JS heap under 100 MB:

EXC_BAD_ACCESS (SIGSEGV), thread com.facebook.react.runtime.JavaScript
hermes::hermes_fatal
hermes::vm::GCBase::oom
hermes::vm::HadesGC::OldGen::allocSlow
hermes::vm::HadesGC::youngGenCollection

Comparison with 0.10.3, measured in the same app on React Native 0.81.5 (the repro below cannot run 0.10.x because it uses React Native 0.86): decoding one chunk and assigning it to one source reported +100.6 MB on 0.10.3 and +201.2 MB on 0.13.6, and the same stress run took about twice as long to hit the limit on 0.10.3 (7 min 48 s versus 3 min 35 s). Process RSS grew by about the same amount for that chunk on both versions (about 150 MB). So the per-assignment cost appears to have been introduced after 0.10.3; the repro shows identical numbers on 0.12.2 and 0.13.6.

This looks related to #1263 (repeated seek with the same AudioBuffer leaks native heap on Android, ending in a Hermes GC OOM) and to the open PR #1283, and possibly to #1266. What this report adds: it reproduces on iOS, it gives a minimal app with per-step numbers, and it shows the amounts reported to Hermes through external memory accounting, including the 2x factor on a plain decode and the 4x that remains after the references are dropped. Happy to have it closed as a duplicate of #1263 if you prefer to track it there.

Steps to reproduce
  1. Clone the repro, npm install, npx expo run:ios.
  2. Press "Run". The app builds a 131 s stereo 48 kHz PCM16 WAV in memory and then, waiting 1 s after each step, reads HermesInternal.getInstrumentedStats().js_externalBytes.
  3. Compare each step's increase with the raw PCM size (buf.length * buf.numberOfChannels * 4).

Result on 0.13.6 (identical on two launches, and identical on 0.12.2), in MiB:

Step externalBytes delta delta / raw PCM
baseline 0.0
WAV ArrayBuffer created (24.0 MiB) 24.0 +24.0 0.50
new AudioContext() 24.0 0.0 0.00
await ctx.decodeAudioData(wav) 119.9 +95.9 2.00
createBufferSource(), src.buffer = buf, connect 215.9 +95.9 2.00
src.start(), src.stop() after 1 s 215.9 0.0 0.00
5 more sources, same buf assigned, not started 695.6 +479.7 10.00
all references dropped 191.9 -503.7 -10.50
5 s later 191.9 0.0 0.00

"Loop x30" in the same app (decode, new source, assign, drop, 30 times) cycles between 408, 504 and 600 MiB and drops back every third iteration, so in this simple loop the collector keeps up. Process RSS still climbed from about 450 MB to about 1.8 GB over that loop.

Expected: assigning an existing AudioBuffer to another source node should not add a full buffer's worth of memory, and the amount reported to the engine should match what is actually held.

Snack or a link to a repository

https://github.com/VikalpP/audio-api-external-memory-repro

React Native Audio API version

0.13.6 (same numbers on 0.12.2; not present on 0.10.3)

React Native version

0.86.3 (Expo SDK 57.0.27)

Platforms

iOS

JavaScript runtime

Hermes

Workflow

Expo Dev Client

Architecture

Fabric (New Architecture)

Build type

Debug mode

Device

iOS simulator

Device model

iPhone 18 Pro (iOS 27.0), Xcode 27.0

Acknowledgements

Yes

Lingua principale
C++
Stelle
848
Fork
94
Merge medio
4g 20m
PR unite (30g)
31

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di software-mansion/react-native-audio-api

Tutte le issue di software-mansion/react-native-audio-api

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.