Thread-local variables corruption after setjmp/longjmp with threads+dynlink

[Faless]

While working on the Godot web port, trying to build a threads+dynlink binary I stumbled upon some weird deadlocks which traced back to corrupted thread-local variables after doing a setjmp/longjmp on the main thread.

Here is a minimal reproduction:

// side.cpp
#include <emscripten/emscripten.h>
#include <iostream>
#include <setjmp.h>
#include <assert.h>

static thread_local bool v1 = false;
static thread_local int v2 = 42;

void JB(jmp_buf *buf) {
	longjmp(*buf, 1);
}

void JA() {
	jmp_buf buf;
	if (!setjmp(buf)) {
		std::cout << "Jump set" << std::endl;
		JB(&buf);
	} else {
		std::cout << "Jump over" << std::endl;
	}
}

extern EMSCRIPTEN_KEEPALIVE int js_main(int argc, char *argv[]) {
	v1 = true;
	v2 = 12;
	std::cout << "Started!" << std::endl;
	assert(v1 == true);
	assert(v2 == 12);
	JA();
	// One of the following fails
	assert(v1 == true);
	assert(v2 == 12);
	std::cout << "Over!" << std::endl;
	return 0;
}

// main.cpp
extern int js_main(int argc, char *argv[]);

int main(int argc, char *argv[]) {
	return js_main(argc, argv);
}

Build with:

em++ side.cpp -Os -s USE_PTHREADS=1 -o side.wasm -s SIDE_MODULE=2
em++ main.cpp -Os -s USE_PTHREADS=1 -o main.html -s MAIN_MODULE=1 side.wasm

Or see the attached zip for both sources and binary (compiled with emcc 2.0.24)

thread_local.zip

[sbc100]

Thanks for the report. Interesting/useful that you don't even need to start any threads to reproduce.

[kripken]

cc @tlively as this is about thread-local.

[tlively]

Thanks for the cc, @kripken! @sbc100, the dylink stuff makes me think this is in your bailiwick, but let me know if you want help looking at it.

[sbc100]

This looks related to the fact the TLS variables cannot be exported across module boundaries today. Its one of the limitations of pthreads + dynamic linking that we have right now.

The codegen for setjmp/longjmp lowering on llvm generates references to __THREW__ and __threwValue in the side module code but these are defined in the main module.

The mystery is why we don't see a linker error here... I'm continuing to investigate that part.

[sbc100]

Indeed, this is not a supported configuration right now since setjmp/longjmp rely on cross module TLS variables which are not yet supported with threading.

Once this lands you will see a nice error at link time: https://reviews.llvm.org/D106385