Memory corruption when compiling dylink + pthreads + exceptions

[jprendes]

The following example seems to constantly result in a memory corruption.
This happens regardless of whether I am actually spinning a new thread or not (as in the example).

main.cpp

#include <stdio.h>
int get_value(char c); // from side module
int main(void) {
    printf("%d\n", get_value('x'));
    return 0;
}

side.cpp

#include <string>
int get_value(char x) {
    std::string value = "123";
    value.push_back(x);
    return value.length();
}

I am compiling with

em++ -s ASSERTIONS=1 -g -pthread -Wno-experimental -s DISABLE_EXCEPTION_CATCHING=0 -s SIDE_MODULE=1 -o side.wasm side.cpp
em++ -s ASSERTIONS=1 -g -pthread -Wno-experimental -s DISABLE_EXCEPTION_CATCHING=0 -s MAIN_MODULE=1 -s EXIT_RUNTIME=1 -s RUNTIME_LINKED_LIBS=['side.wasm'] -o main.html main.cpp

The example correctly prints 4, but then it is followed by

Uncaught RuntimeError: abort(Runtime error: The application has corrupted its heap memory area (address zero)!) at Error
    at jsStackTrace (http://127.0.0.1:8080/main.js:2201:19)
    at stackTrace (http://127.0.0.1:8080/main.js:2751:16)
    at abort (http://127.0.0.1:8080/main.js:1567:44)
    at checkStackCookie (http://127.0.0.1:8080/main.js:1339:46)
    at exitRuntime (http://127.0.0.1:8080/main.js:1405:3)
    at exit (http://127.0.0.1:8080/main.js:54481:5)
    at callMain (http://127.0.0.1:8080/main.js:54338:7)
    ...

[jprendes]

This seems to happen when a noexcept function calls a function that "could" throw. This seems to be the case with musl's allocators, used by std::string in my previous example.

Here's an example:

main.cpp

#include <stdio.h>
int get_value();
int main(void) {
    printf("%d\n", get_value());
    return 0;
}

side.cpp

#include <stdlib.h>
int some_function() noexcept {
    return atoi("42");
}
int get_value() {
    return some_function();
}

And here's another example that doesn't require any library:

main.cpp

int random() {
    return 42;
}
int get_value();
int main(void) {
    return get_value();
}

side.cpp

int random();
int some_function() noexcept {
    return random();
}
int get_value() {
    return some_function();
}

In both cases removing the noexcept everything works as expected.
Both examples are compiled with the same commands from the previous post.

It looks like the compiler is generating code that required thread local storage, but doesn't actually allocate any when the thread starts.

In both cases the generated side.wasm file contains:

  (global $__tls_base (;3;) (mut i32) (i32.const 0))
  (global $__tls_size (;4;) (export "__tls_size") i32 (i32.const 0))
  (global $__tls_align (;5;) (export "__tls_align") i32 (i32.const 0))
  ...
  (func $__wasm_init_tls (;2;) (export "__wasm_init_tls") (param $var0 i32)
  )

the module claims to require 0 bytes of tls, and tls init is actually empty, where normally it would assign __tls_base and initialize the memory.

In both cases the definition of some_function starts as follows, where __tls_base is not initialized and has a value of 0.

  (func $_Z13some_functionv (;9;) (export "_Z13some_functionv") (result i32)
    (local $var0 i32) (local $var1 i32) (local $var2 i32) (local $var3 i32) (local $var4 i32) (local $var5 i32) (local $var6 i32) (local $var7 i32) (local $var8 i32) (local $var9 i32) (local $var10 i32) (local $var11 i32) (local $var12 i32) (local $var13 i32) (local $var14 i32)
    i32.const 0
    local.set $var0
    global.get $__tls_base
    local.set $var1
    local.get $var1
    local.get $var0
    i32.add
    local.set $var2
    i32.const 0
    local.set $var3
    local.get $var2
    local.get $var3
    i32.store

It is this last store in the listing that corrupts the memory cookie.

[jprendes]

Ok, it turns out that exceptions + pthread shares TLS data addresses with JS, which is mentioned as a missing feature in @sbc100 's initial commit for dylink + pthread.

Adding TLS support and making sure that side modules are linked against emscripten's exceptions builtin code should fix this issue.