Arguments missing in calls to _emscripten_proxy_to_main_thread_js

[Soeren Balko]

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

[Soeren Balko]

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

[Alon Zakai]

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

--
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 emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.