Same AudioContext for two Modules causes memory corruption

[lindell]

Version of emscripten/emsdk:
4.0.13 (but verified in code this should still exist on HEAD)

Description:

Using the web audio API with one AudioContext but with two or more modules does not work, as the second one will try silently the memory of the first one, causing memory failures.

Example:

  const audioContext = new AudioContext();

  const mainModule = await createModule();
  const audioContextId = mainModule.emscriptenRegisterAudioObject(audioContext);
  mainModule.functionThatStartsAWorklet(audioContextId);

  const mainModule2 = await createModule();
  const audioContextId2 =
    mainModule2.emscriptenRegisterAudioObject(audioContext);
  mainModule2.functionThatStartsAnotherWorklet(audioContextId2);

Where functionThatStartsAWorklet and functionThatStartsAnotherWorklet starts AudioWorklets.

---

addModule will succeed, at least if the same URL is used.

But since it is set up with the wasmModule and memory only once for the AudioContext. When starting another worklet, from another module, both will use the same memory even though they should be using separate ones. This causes memory corruptions, and usually crashes for one or both of the worklets.

[lindell]

@cwoffenden

[cwoffenden]

Are you passing in the same stack or are you allocating one per audio worklet like this:

emscripten/test/webaudio/audioworklet_test_shared.inc

Line 107 in 80269bf

char* const workletStack = memalign(16, AUDIO_STACK_SIZE);

[lindell]

I'm using uint8_t audioThreadStack[4096]; But that should not really matter? Since the two emscripten Module instances have different memories.

[cwoffenden]

Are modules not sharing the same shared array? From what you describe as running using memory of the other, I'd first look at allocating the stack instead of passing in the array.

[lindell]

They are not using the same memory, that is the core of this issue. With the same instance/memory you should be able to register/create as many Worklets as you want without any problem. createModule() is the factory function which create another instance.

But just to be sure. I change the stack creation to this

  void* const workletStack = memalign(16, AUDIO_STACK_SIZE);

  emscripten_start_wasm_audio_worklet_thread_async(
      audio_context, workletStack, AUDIO_STACK_SIZE, &AudioThreadInitialized,
      user_data);

And I still get Uncaught RuntimeError: memory access out of bounds

[cwoffenden]

Now I understand, the errors are because the second instance can't see the memory of the first (I understood it to be writing over the same space).

[lindell]

I understood it to be writing over the same space

That is what I think is happening.

Let me added some additional context. For simplicity, I assume that global scope message ports is not enabled in the following example.

What is done:

1. An audio context is created
2. An Module instance is created by calling the factory method. This will create the SharedArrayBuffer to be used for this instance only.
3. A function is called on the Module from 2. which
   1. Calls emscripten_start_wasm_audio_worklet_thread_async to setup everything in the AudioContext.
   2. emscripten_create_wasm_audio_worklet_processor_async is called with a unique name for the AudioContext to register a new Worklet Processor.
   3. We can now initialize the Worker, but it is technically not necessary.
4. Repeat 2
5. Repeat 3

Expectation: We now have two AudioWorkletProcessors registered (and started?) in the AudioContext. Each with its own memory since they are created by different instances from the Main Thread.

What is actually happening

In 5.1, the em-bootstrap AudioWorkletProcessor will be the same as for 3.1. This includes setting the wasmMemory/wasmModule blocked scoped here:

• https://github.com/emscripten-core/emscripten/blob/80269bf4e700951847b4ef350605b7052ec05aa3/src/audio_worklet.js#L276C5-L276C20

• emscripten/src/wasm_worker.js

  Line 14 in 80269bf

  wasmMemory = props.wasmMemory;

In 5.2, when registering the new processor, any call into Wasm will now be made into the module created in 2. instead of the one created in 4. which the code assume it will do. This is the case both for Emscripten code in the Worklet like this. But also any user code that will be run within the registered process function.

Since the second instance within the AudioContext will try to use the other instances memory, will cause out of bound reads / memory corruptions / etc.