OK, so I found the cause for this issue. Seems like things get astray
inside jsifier.js when using the LIBRARY_DEBUG=1 flag in parallel to
USE_PTHREADS=1. Both flags cause pattern-matching inside the generated
Javascript code, replacing it with other stuff. This is...ahem...an
interesting choice for a compiler backend. ;-) Anyway, both features
effectively patch up the generated Javascript, conflicting with one another.
Removing the LIBRARY_DEBUG=1 flag seemingly fixes the problem.
Soeren
On Wednesday, March 13, 2019 at 2:23:03 PM UTC+10, Soeren Balko wrote:
>
> We have noted a regression pertaining to threads support, which has
> occurred somewhere between 1.28.16 and 1.38.29 (still bisecting). For
> standard library functions that must be dispatched to the main thread such
> as getenv(...), Emscripten used to generate code like this:
>
> function _getenv(name) {
> if (ENVIRONMENT_IS_PTHREAD) return
> _emscripten_sync_run_in_browser_thread_ii(1, name);
> // char *getenv(const char *name);
> //
> http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html
> if (name === 0) return 0;
> name = Pointer_stringify(name);
> if (!ENV.hasOwnProperty(name)) return 0;
>
> if (_getenv.ret) _free(_getenv.ret);
> _getenv.ret = allocateUTF8(ENV[name]);
> return _getenv.ret;
> }
>
>
> This has now changed into something like that:
>
> function _getenv(name) { var ret = (function() {
> if (ENVIRONMENT_IS_PTHREAD) return
> _emscripten_proxy_to_main_thread_js(21, 1, );
> if (runtimeDebug) err("[library call:_getenv: " +
> Array.prototype.slice.call(arguments).map(pret$
> // char *getenv(const char *name);
> //
> http://pubs.opengroup.org/onlinepubs/009695399/functions/getenv.html
> if (name === 0) return 0;
> name = UTF8ToString(name);
> if (!ENV.hasOwnProperty(name)) return 0;
>
> if (_getenv.ret) _free(_getenv.ret);
> _getenv.ret = allocateUTF8(ENV[name]);
> return _getenv.ret;
> }).apply(this, arguments); if (runtimeDebug && typeof ret !==
> "undefined") err(" [ return:$
> }
>
>
> Note that _emscripten_sync_run_in_browser_thread_ii(...) was turned into
> _emscripten_proxy_to_main_thread_js(...) and that the arguments to the
> latter are truncated. I checked all calls to
> _emscripten_proxy_to_main_thread_js in the generated code and all but one
> seem to suffer from that. The oine that doesn't have the problem is for
> tzset(), which doesn't take any parameters. The ones that do have the
> problem are for:
>
> - sysconf(...)
> - __syscall140(...)
> - __syscall145(...)
> - __syscall146(...)
> - __syscall192(...)
> - __syscall195(...)
> - __syscall197(...)
> - __syscall220(...)
> - __syscall221(...)
> - __syscall3(...)
> - __syscall33(...)
> - __syscall340(...)
> - __syscall38(...)
> - __syscall4(...)
> - __syscall5(...)
> - __syscall54(...)
> - __syscall6(...)
> - __syscall75(...)
> - __syscall77(...)
> - __syscall91(...)
> - emscripten_set_canvas_element_size_main_thread(...)
> - getenv(...)
>
> So this looks like a regression to me. Our settings are this:
>
> -s ENVIRONMENT=worker \
> -s USE_PTHREADS=1 \
> -s EXCEPTION_DEBUG=1 \
> -s LIBRARY_DEBUG=1 \
> -s SYSCALL_DEBUG=1 \
> -s PTHREADS_DEBUG=1
> -s PTHREAD_POOL_SIZE=8 \
> -s TOTAL_MEMORY=536870912 \
> -s PROXY_TO_PTHREAD=1 \
> -s ASSERTIONS=2
> -s USE_OGG=1 \
> -s USE_VORBIS=1 \
> -s USE_ZLIB=1 \
> -s PRECISE_F32=2 \
> -s DOUBLE_MODE=0 \
> -s INVOKE_RUN=0 \
>
>
> I'll play around with the latter to confirm that nothing in there is
> causing this. Would be great though to get some confirmation from others
> that this is a bug/regression.
>
> Thanks.
> Soeren
>
>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
