Uncaught RuntimeError: unreachable from worker

[jozefchutka]

Version of emscripten/emsdk:
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.1.32 (eab98ad)
clang version 17.0.0 (https://github.com/llvm/llvm-project df82394e7a2d06506718cafa347bf7827c79fc4f)
Target: wasm32-unknown-emscripten
Thread model: posix

I am building svt-av1 v1.4.1 for ffmpeg with emscripten 3.1.32. I managed to successfully compile to wasm, but during runtime (in browser worker), I am getting these exceptions:

)

First I thought this might be related to large number of processes/workers being opened, however I can restrict the count to some reasonable ~20 which is tested safe with some other examples.

Here are my compilation flags, I think I am being generous with memory:

-s INITIAL_MEMORY=256mb
-s ALLOW_MEMORY_GROWTH=1
-s MAXIMUM_MEMORY=4gb
-s ENVIRONMENT=worker
-s PROXY_TO_PTHREAD=1
-s STACK_SIZE=10MB
-s DEFAULT_PTHREAD_STACK_SIZE=4MB
-pthread

...also -msimd128 is being used.

At this point I am not sure this to which technology the error is related to (emscripten, webassembly, svtav1) but considering the error message (note attached screenshot) I will have hard time reporting error to svtav1 issue tracker and so decided to ask here first.

I would like to kindly ask the elders of the emscripten if this appears like something to be fixed on emscripten side?

[sbc100]

Sometimes when you hit a unreachable instruction like that is due to undefined behaviour the C/C++ language.

One way to start tracking it down would be to start simplifying your program to try to narrow now the place there that undefined behaviour might be.

First of all, you will probably want to rebuild with --profiling-funcs so that devtools will at least show you the name of the function in question.

Can you reduce the number of threads? What about reducing it to just 1? Does the problem still occur? How about if you remove -msimd128? How about if you remove memory growth? By trying to simplify and remove flags we might be able to get a clearer picture of the problem.

[jozefchutka]

Thanks for the heads up, with --profiling-funcs I managed to reveal the function name picture_manager_kernel

Uncaught RuntimeError: unreachable
    at picture_manager_kernel (ffmpeg-lgpl.wasm:0x85c246)
    at Object.invokeEntryPoint (ffmpeg-lgpl-wv.js:8:70499)
    at handleMessage (ffmpeg-lgpl.worker.js:1:1796)

I have also removed simd, memory growth, but not able to reduce to single core single thread execution.

I am considering reaching out to SVT-AV1 team at this point. Or do you have any other idea?

[sbc100]

Do removing simd and memory growth, the problem persists? But removing threading makes the problem does not persist?

Can you post your new minimum set of flags needed to reproduce? I'm curious about -sENVIRONMENT=worker ? Does that mean you are starting your application from within an already created worker worker? i.e. you are not loading this module on the main thread at all? In that case do you actually need -sPROXY_TO_PTHREAD .. that option is normally to avoid blocking the main thread.. but is likely not needed if you are already running off-the-main-thread.

[jozefchutka]

The problem persists even after removing simd and removing memory growth. FFmpeg can not be built without pthreads so that needs to stay. You assumed correctly, I am starting ffmpeg wasm from within an exiting worker.

Here is a complete set of flags used. All the other encoders are working fine, and ffmpeg wasm is running stable. Its just this new svtav1 I tried to add is problematic.

btw the test command line looks as follow:

ffmpeg -filter_complex smptehdbars=size=320x240:rate=30:duration=5
-pix_fmt:v yuv420p
-c:v libsvtav1 -pix_fmt yuv420p -svtav1-params lp=1
out.mp4

I havent tried yet without -sPROXY_TO_PTHREAD, but I expect the same error. I will surely experiment with it.