The problem here was that the asan_c_load_4 etc. methods, that are tiny
functions in C that we let ASan instrument, and then JS calls into, were getting
processed by Asyncify. And we end up calling those asan_c_* methods
during critical Asyncify times like as we begin to rewind - times when it is
not valid to call into instrumented code, or we assert. To fix that, simply
ignore those specific methods in Asyncify - we don't need to process them
anyhow, as they cannot pause.
One test remains broken, test_asyncify_lists_onlylist_d, which I left as
a TODO. That test does something invalid, and it is expected to fail, but
it fails in a different way somehow. The details get complicated due to how
ASan modifies things. Let's leave #14807 open for that.
For some reason we were ignoring the contents of
`DEFAULT_LIBRARY_FUNCS_TO_INCLUDE` when building with
`INCLUDE_FULL_LIBRARY` which means we were not reporting undefined
symbols in this case, and in particular not auto-generating the needed
`__cxa_find_matching_catch` functions in the case of exception handling.
Fixes: #13794
In pthreads mode, TextDecoder is wrapped in a special way. The logic there
receives buffers and copies them. It asserts the buffer is a Uint8array. The
dylink code hits that assertion as it creates a Int8Array and sends it there.
We could make the wrapper support signed views too, but it seems simpler
to just use the same unsigned view there, which is clearer anyhow.
Fixes#14833
The `_abort` library function gets proxied back to the main thread so
doesn't env up calling this function. However direct calls to the
`abort` runtime function can occur in JS code. More importantly
worker.js defines `assert` in terms of abort:
```
function assert(condition, text) {
if (!condition) abort('Assertion failed: ' + text);
}
```
Without this fix `assert` calls from `worker.js` will end up in infinite
recursion.
Also, when AUTO_JS_LIBRARIES is set to 0 (as it is by default in
MINIMAL_RUNTIME mode) we don't want to be including SDL by default
(since it depends on other JS libraies such as library_browser.js).
Split the logic from `pthread_exit` into `_emscripten_pthread_exit`
so it can be called after return from thread main rather than just
the `threadExit` part.
This is a useful precursor to the musl upgrade where the native
component of `pthread_exit` has non-trivial functionality.
Calling `_emscripten_pthread_exit` can also be used to perform
a thread exit without the `unwind` exception being thrown.
Simply use `pthread_exit` avoid the extra `EM_ASM` and specific new
exception string.
This also happens to be how much implements this. See
musl/src/thread/pthread_cancel.c
STANDALONE_WASM flushes its std streams on exit via calling
`__stdio_exit` (from musl/src/stdio/__stdio_exit.c) form `exit` (from
musl/src/exit/exit.c).
In the .js generated by file_packager.py which currently produces the following attributes for each file,
{"filename":"<path>","start":<start>,"end":<end>,"audio":0}
(exemple here) only store the audio attribute when it's set to 1. Otherwise assume that it is 0 (which should be the case for the vast majority of files). Resulting in,
{"filename":"<path>","start":<start>,"end":<end>}
This saves 9 bytes per file, or in the above linked example about 10kB for 1100 files.
Related to #14695
This mode means that unhandled promise rejections will be thown as
exceptions which means that the process will exit with a non-zero return
code. This is the default mode in v15 and above but we still use v14
and we want this behaviour when running our tests to make sure we don't
silently ignore any unhandled rejections.
See https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode.
This test was disabled back in 03ba458a16.
Keeping this dead code around is a maintenance burden. We can resurect
it from history if needed.
Also remove the commented out test above.
Previously we were silently ignoring it. We considered the alternative
which would be to automatically enable ALLOW_MEMORT_GROWTH but decided
that would be more of a breaking/surprise change.
This means that we don't need to build all our static libraris (e.g.
libz.a) with `-fPIC`. I guess gcc at some point made `-pie` the default
(or at least the gcc installation on my machine seems to be configured
that way).
Alternative to #14793
Without this the parent node process will continue, which is especially
bad in `PROXY_TO_PTHREAD` and test code since the node process will never
exit.
As part of this change we also avoid re-throwing `unwind` exceptions.
`unwind` exceptions, just like `ExitStatus` exceptions are designed simply
to unwind the stack and should never reach the outermost frame / event
loop.
Should help with #14344 (at least it should prevent the uncaught unwind issue).
* Added timestamp to EmscriptenTouchEvent
* Added myself to AUTHORS
* Update src/library_html5.js
Co-authored-by: Alon Zakai <alonzakai@gmail.com>
* Added timestamp member to EmscriptenTouchEvent
* Added timestamp to EmscriptenMouseEvent & EmscriptenKeyboardEvent
* Added timestamps to test_html5_core test
* Updated reference_struct_info.json with new timestamp field in EmscriptenKeyboardEvent & EmscriptenMouseEvent
Co-authored-by: Alon Zakai <alonzakai@gmail.com>
This allows pthread initialization, for example, to call malloc.
This is an alternative to
ttps://github.com/emscripten-core/emscripten/pull/14774 which avoids the
static constructor completely.
Fixes: #14766
It was previously possible for MAXIMUM_MEMORY to be set to -1. In
fact it was the default. However since #10601, it is no longer the
default and there is no way to set it to -1.
This test was essentially don't doing anything since we switched
to exported memories since it was never finding the line in the wat
file that it was looking for.
- Rename the test to test_memory_size
- Look for exported memory (and fail if its not found)
- When ALLOW_MEMORY_GROWTH is not specified we currently ignore
MAXIMUM_MEMORY (we can decide it we want to change that but for
now this is test of the existing behaviour).
Refactored the existing test and re-enabled it. This had
bit rotted in the mean time which meant that EMCC_FORCE_STDLIBS=1
was getting duplicate symbols.
Fixes: #10571Fixes: #11703
This also avoids the use of malloc both for the main pthread struct and
for its TLS vars. This in turn avoids the use of `withBuiltinMalloc`
since we no longer use malloc here.
These checks are rather pointless since we don't run any of these tests
without thread support enabled.
There are also several downsides to including this check everywhere:
1. Could lead to false positives since the fallback is simply to
return zero (success).
2. Prevents the tests from being compiled and run outside of emscripten.
3. Add needless complexit to tests and needless includes of
emscripten-specific headers.
There are some tests that actually do look like they are designed to be
run in two different modes: with real threading and with stubs. I left
those tests alone, even those I can't see any cases were we actually run
those tests without pthreads enabled in the test suite.