Thanks for noticing this! Yeah, both options modify the JS library, and one
did it incorrectly. Fix in

https://github.com/emscripten-core/emscripten/pull/8303

Please test it if you can.

- Alon


On Tue, Mar 12, 2019 at 11:41 PM Soeren Balko <[email protected]> wrote:

> 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.
>

-- 
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.

Reply via email to