Inspired by this discussion, I added the default values to the settings
HTML page now in
https://github.com/emscripten-core/emscripten/pull/21943
For example here is STACK_SIZE:
https://emscripten.org/docs/tools_reference/settings_reference.html#stack-size
- Alon
On Tue, May 14, 2024 at 6:51
That is very strange. Based on those link flags, you did not modify how the
application starts up, so I have no idea how it could break like that. If
it only happens in the Firefox debugger then perhaps it is a Firefox
debugger bug somehow? That seems unlikely too. But maybe try debuggers in
other
The Acorn optimizer runs on code that is combined with the Emscripten JS
output. That is the main JS output, including JS library support, and also
--pre/post-js and EM_ASM code, which are combined and then optimized as one
(which is good for DCE).
On Tue, Apr 2, 2024 at 8:38 AM 'Michael Hagar'
I don't know enough to answer that question, but I suggest asking it on the
PR, as the authors might not see things here on the mailing list, but will
definitely see it there:
https://github.com/emscripten-core/emscripten/pull/20802
On Sat, Dec 16, 2023 at 4:30 AM キャロウ マーク wrote:
>
>
> On
The Emscripten ChangeLog.md file has information about all breaking changes
as well as other major updates:
https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md
On Mon, Dec 4, 2023 at 3:19 PM Mahesh Velankar wrote:
> I started using emscripten in Dec 2021 and have my webpage
The simplest thing is
emcc --clear-cache
which deletes all built libraries. They are then rebuilt on demand next
time you run emcc.
More generally, you can use embuilder. embuilder --help will show the
available commands. (Note you need to use --force to rebuild an already
built library.)
On
The JS file that the file packager creates depends on the emscripten
runtime code, so you do need to compile a program to use it. But perhaps
you can compile a small one. Then you just combine the JS from that with
the JS from the file packager and it should work. There are examples of
this in the
That error might be because we do not export all functions by default. Try
with
emcc -sEXPORTED_RUNTIME_METHODS=addRunDependency
On Sun, Jul 16, 2023 at 7:22 AM Ronny Nissengold
wrote:
> Hi all,
> By giving the linker the --preload-file flag with the appropriate folder I
> was able to
Thanks, good to know that this is being used. Sam already mostly convinced
me to keep SDL1 around already, so with this information I think we can
decide to keep it.
- Alon
On Fri, Jun 9, 2023 at 3:02 AM Александр Гурьянов
wrote:
> I use SDL 1 in many project, because it's more lightweight,
On Wed, Jun 7, 2023 at 12:41 PM 'Sam Clegg' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
>
>
> On Wed, Jun 7, 2023 at 10:29 AM Alon Zakai wrote:
>
>> Yeah, this is tricky. I agree with Floh that our early ports of glfw etc.
>> are of limited u
Yeah, this is tricky. I agree with Floh that our early ports of glfw etc.
are of limited use. Ideally they'd all be done like SDL2, that is, be in
upstream + use emscripten HTML5 C APIs as much as possible, to get
consistent input event handling etc., which is a common issue as you said,
Sam.
Hi everyone,
I wonder if we still need our SDL1 (SDL 1.2, specifically) implementation
at this time, given that we have excellent and stable SDL2 support?
Context: SDL1 has been deprecated for many years now [1]. SDL2 is a
decade old at this point [2], and other projects have removed SDL1
; Hello!
>>> Does it make sense to bump version to even numbered node release:
>>> https://nodesource.com/blog/understanding-how-node-js-release-lines-work/
>>>
>>> Odd numbered releases are killed soon and LTS is only for even number
>>> releases.
>>
Hi everyone,
We are considering bumping the default minimum node version for
emscripten-generated code, from 10.19 to 15.0:
https://github.com/emscripten-core/emscripten/pull/19192/files
The main motivation is that 10.19 is quite old at this point so most people
are likely using newer versions.
On Tue, Apr 4, 2023 at 7:45 PM Mark Sibly wrote:
> I'm building a 3rd party c++ lib in emscripten that uses pthreads, and I'm
> finding that I have to use -sPTHREAD_POOL_SIZE=23 for it to work, otherwise
> it hangs.
>
> I did think leaving out -sPTHREAD_POOL_SIZE (or setting it to 0) would
>
You can use an older version by doing
emsdk install 1.38.13
In some cases you may also need to use an older emsdk for that. To do so,
you can checkout the 1.38.13 tag in the emsdk repo. If you still see
issues, try doing so in a new checkout of the emsdk perhaps.
In general, if you see issues
To add to that, as I mentioned on Discord, Emscripten output should just
work in plain V8, or at least the d8 shell, using the "shell" environment.
Maybe one or two minor d8 additions like a way to load a binary file would
be needed in plain V8, but that's it.
- Alon
On Wed, Feb 15, 2023 at
Are you saying LLVM optimizations cause try-catch to appear? That seems odd
to me. Unless it really is simply because of inlining - in that case
[[noinline]] can help.
Otherwise I think try-catch like those, which are really just to call
std::terminate() on an exception, are added by clang in
Bisection might be useful here, as in theory any LLVM change could cause
such a difference or a bug. It's pretty simple to bisect using the emsdk:
https://emscripten.org/docs/contributing/developers_guide.html#bisecting
On Tue, Dec 6, 2022 at 4:22 PM Gregory Propf wrote:
> I just noticed
Hmm, this doesn't sound like a known issue. You can build with EMCC_DEBUG=2
in the env, and then the temp JS files will be saved in
/tmp/emscripten_temp. Reading the last JS one around the line it has the
syntax error on might give a clue.
On Mon, Nov 28, 2022 at 10:31 AM Gregory Propf wrote:
>
First thing, I would try -O2 and -Os. They can be much faster than -O3 and
-Oz.
Otherwise, 10-12 minutes sounds extreme even for 12MB, so this is likely
hitting an unknown bad case. If you can run a system profiler on it that
might show something useful. You can also run with
On Mon, Apr 25, 2022 at 1:51 AM 'paw' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> Hello everyone,
>
> At my work, we create a tool which runs in the Web Browser but uses native
> components. These are compiled with emscripten to *asm.js* (we plan to
> transition to wasm
There is now this Zig issue for emscripten discussion, more details might
make sense to add there, if any,
https://github.com/ziglang/zig/issues/10836
On Tue, Feb 1, 2022 at 3:44 AM Floh wrote:
> > Btw, did you get a chance to file a Zig ticket as you said?
>
> Haven't done that yet!
>
> On
t is what I naively tried to do. The CoreCLR runtime is compiled
> using emscripten's SDK, but I wanted to link it with the WASI SDK libc++ to
> get file open support. What I'll probably have to do in the long run is
> have two CoreCLR runtimes, one for Emscripten and one for WASI SDK.
>
les/triangle/main.c
>
> So when I say sdl/glfw + wgpu-native, I mean that I will use c/c++
> sdl/glfw for windows/events and wgpu-native for graphics.
>
> сб, 5 февр. 2022 г. в 00:31, Alon Zakai :
>
>> Wow, great that you got all that working!
>>
>> I'm also interest
Header constants like O_CREAT should not be a problem between wasm and the
host. WASI defines a very clear API between wasm and the runtime, and those
constants are not part of it. That is, "wasi-sdk host" is a confusing way
to put it: there are VMs with WASI support, but they are not tied to the
;> link them with emcc, and it produce wasm without any error!
>>>>>>>
>>>>>>> Also I do the same with native build - it works fine.
>>>>>>>
>>>>>>> However, when I tries to run it fails with assertion.
>>
Nice, good to see pacman working!
Btw, did you get a chance to file a Zig ticket as you said?
On Mon, Jan 31, 2022 at 1:53 AM Floh wrote:
> PS: the missing __stack_chk_* symbol errors I mentioned formerly are
> unrelated to the target triple, but instead happen when compiling via Zig
> in
Sam can confirm, but I would guess perhaps the emscripten triple is
necessary. That is, clang and/or wasm-ld might do something for EM_JS code
but only in emscripten mode.
If we can confirm that then we should definitely get a bug filed on Zig -
hopefully it would be easy to add support for the
u try it out, let us know how it goes!
- Alon Zakai
P.S. See more details in that PR if you're curious.
--
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 a
he workaround could be what I mentioned
for Zig and C before: get Rust to link to a static library, and then run
emcc manually on that.
(Alternatively, in theory someone could look into supporting wasm-bindgen +
emscripten.)
- Alon
> пт, 14 янв. 2022 г. в 07:54, Alon Zakai :
>
&g
That sounds great!
- Alon
On Sat, Jan 15, 2022 at 1:03 AM Sebastian Theophil
wrote:
>
> Am 12.01.2022 um 19:06 schrieb Alon Zakai :
>
>
> I just have some general thoughts at this point. Curious to hear your
> ideas and other people's.
>
> Maybe a nice startin
Thanks, good to know at least 2 people would read a post about this :) I'll
try to find time for it.
About Rust, I haven't had time to look into it yet. My general hope is that
the same model as for C and Zig could work:
1. Tell Rust to use the emscripten wasm triple.
2. Tell Rust to compile to
On Sat, Dec 25, 2021 at 6:02 AM Floh wrote:
> Ah, language and toolchain interoperability, one of my favourite topics ;)
>
> Zig has nearly the same problems as Rust: it allows to compile to WASM, it
> has both a WASI and Emscripten target, with the WASI target working out of
> the box, but I
Very interesting writeup, thanks!
It is sad that things don't work better here. The Emscripten side is
focused on C/C++ obviously and on native API support while the Rust side is
focused on either pure computation or on calling Web APIs. For something
like Vange-rs you really want native APIs +
still need to be implemented for a good MVP, so to speak.
>
> Regards
> Sebastian
>
> Am Do., 6. Jan. 2022 um 21:59 Uhr schrieb Alon Zakai >:
>
>> Hi Sebastian,
>>
>> This is really nice! I watched your talk as well at CppCon (
>> https://www.youtube.com/watc
You can use bisection to find out exactly where a speedup came from,
basically the same as finding a regression,
https://emscripten.org/docs/contributing/developers_guide.html#bisecting
That would give you a single (and hopefully short) list of commits in a
single tool (LLVM or Binaryen, but not
bindings story (atm we have embind and the WebIDL
binder, which already have some overlap).
- Alon Zakai
On Tue, Dec 28, 2021 at 2:21 AM Sebastian Theophil
wrote:
> Hi,
>
> I wanted to plug my own project for some time here on the mailing list
> because it also handles JavaScript - C++ int
Looks like that patch landed Dec 2, so it is already in the latest tip of
tree build of emscripten, which people can try with
emsdk install tot
On Tue, Dec 7, 2021 at 5:52 AM 'Thomas Lively' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> Yes, from the description in
to verify.
On Tue, Oct 26, 2021 at 12:43 PM 'Steven Johnson' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> On Tue, Oct 26, 2021 at 12:39 PM Alon Zakai wrote:
>
>> Separately, however, does 16.13.0 have a new-enough SIMD for you?
>>
>
> Good ques
I think our general policy here has been to use the Node that we assume
most people are using anyhow (which seems safest for testing and everything
else). That generally means Node LTS, since it's what the node download
page directs people to, although we've debated that in the past.
It looks
In general, I'm afraid there isn't an automatic and safe way to do this. If
LLVM optimizations change (between -O3 and -Oz, or after an LLVM update
with the same opts) then inlining might cause the call stacks to look
different. If less is inlined, you'd need more functions in your list, if
you
> running into a similar issue but in the browser. I'm curious whether
> there's now a way to support this without modifying the code by any chance?
> Thank you!
>
>
> On Friday, November 8, 2013 at 3:28:09 PM UTC-8 Alon Zakai wrote:
>
>> Simplest option is to writ
Very strange. In that case, what is the type of data.buffer?
The main SharedArrayBuffer is always created in the main thread during
startup. Later growth does not create a new SAB in another thread, it just
grows it, and it updates the views in each thread
using updateGlobalBufferAndViews.
To use cwrap(), you must export it. See
https://emscripten.org/docs/api_reference/preamble.js.html?highlight=cwrap
You can also run an example from the tutorial, which I verified now,
Many things could cause such a difference, including that PNaCl uses LLVM
on the client (which sometimes beats web VMs), the use of SIMD (which must
be enabled explicitly in wasm, but I believe not in PNaCl - you may be
getting autovectorizing), presence of exceptions and setjmp (currently much
There is an experimental --post-link option to create a JS file for a given
linked wasm file. However it isn't aware of SPLIT_MODULE so I am not sure
if it will work here.
On Tue, Apr 20, 2021 at 2:45 AM Александр Гурьянов
wrote:
> Hi. I am trying to use SPLIT_MODULE with Unity. However unity
-pthreads with an "s" is a typo, I think? clang ignores it:
clang-13: warning: argument unused during compilation: '-pthreads'
[-Wunused-command-line-argument]
But -pthread (no "s") is identical to -s USE_PTHREADS.
Jasmeet, I think you need to debug your makefile. COMMON_CFLAGS may not
reach
IMaybe node 12 did not yet have baseline compiler support for wasm. That
could explain the 30 seconds delay, as it fully optimizes all the code
before it runs. Asyncify can generate bigger code, which makes this worse.
A newer node may not have the problem, and should run the baseline compiler
by
+ mkdir ./build
> + em++ v1.cpp -s INVOKE_RUN=0 -s WASM=1 -s MODULARIZE=1 -s SAFE_HEAP=0 -s
> ASSERTIONS=1 -s 'EXPORTED_FUNCTIONS=["_main","_malloc","_free"]' -O0
> --emit-symbol-map -o build/v1.js
> + node v1-test.js
> == FROM OUTSIDE ==
> == FRO
(I think this is separate from minification. We minify wasm imports and
exports, but the HEAP* views are handled entirely in JS.)
On Tue, Feb 16, 2021 at 9:06 AM Floh wrote:
> Just a wild guess: maybe the name has been mangled by the minification
> pass, while in previous emscripten versions it
Hmm, the HEAP* views are always exported,
https://github.com/emscripten-core/emscripten/blob/2e48b2debd5e984cde2cee563f4a359a9d688c46/src/preamble.js#L268-L281
I verified manually that that works in a hello world at all optimization
levels.
Do you have a testcase showing the issue?
On Tue, Feb
Thanks, the docs do look a little out of date. I opened
https://github.com/emscripten-core/emscripten/pull/13417 for that now.
On Tue, Feb 2, 2021 at 11:09 PM Kunza Rizvi wrote:
> I found the conversion to bitcode on a blog post, stackoverflow and the
> emscripten documentation (though the
emscripten-discuss@googlegroups.com> wrote:
>
>> I've seen reports of infinite recursions involving
>> __ubsan_handle_dynamic_type_cache_miss before, but I've never been able to
>> reproduce them to investigate. Would you be able to share your reproducer?
>>
>> On
Does the stack trace look like it's an infinite recursion? That could be a
toolchain bug.
On Wed, Jan 20, 2021 at 11:58 AM 'Maksim Ivanov' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> Hello, does anyone have a tip on how to work around the "Maximum call
> stack size
Interesting...
I'm not sure we can ignore CPATH, as in principle someone might use it
intentionally, and put a path to valid emscripten contents there.
On the other hand if this is common on some OSes then it does seem like
something we should do something about, even if only warn.
On Wed, Nov
WASM=0 still runs the normal compilation pipeline to wasm. It just then
converts the WASM into JavaScript at the very end. (Older versions of
emscripten, that still used fastcomp, used to do things differently.)
What is actually making lld error there? What type of file is ffmpeg.bc?
(running
There is discussion about this in
https://github.com/emscripten-core/emscripten/issues/11362#issuecomment-707357663
(see that and later comments in the issue).
On Thu, Nov 5, 2020 at 3:13 AM Yugesh Kothari
wrote:
> Hi,
>
> How can I use emsdk with a specific version of LLVM that is not top of
> As a hacky workaround, you could always provide your own memory by
setting `Module['wasmMemory']` before loading the generated JS and then set
the memory flag to shared using `wasm-dis + edit + wasm-as`. Obviously not
ideal but maybe good for experimenting.
I don't think that will work now that
We plan to support non-wasm output for a very long time - it's useful for
multiple reasons, including that it can run in old browsers like IE11.
Building with -s WASM=0 is how to do that. Note that it's not asm.js - it
is JavaScript that is similar to asm.js, but not identical (as wasm gains
more
I received a response that this is a known issue in CircleCI's new UI, and
that they are working on it.
This may be a little annoying in the meantime. If anyone opens a PR and has
trouble viewing CI runs, let me know.
- Alon
On Wed, Oct 7, 2020 at 11:24 AM Alon Zakai wrote:
> I ag
I agree this is definitely annoying and unexpected - it should be easy for
someone submitting a PR to see build results. I opened a support ticket now.
Thanks for reporting this Sylvain!
- Alon
On Tue, Oct 6, 2020 at 11:26 PM Sylvain Beucler wrote:
> Hi,
>
> I'd say contact your CI provider
If you build with MAXIMUM_MEMORY=-1 that means "no specified limit". In
that case I think each browser should allow growth as much as it possibly
can.
(see src/settings.js for MAXIMUM_MEMORY for more details, including why
the default is 2GB and not -1, but basically, -1 has some minor code size
You can add this:
function getMemory() {
abort(new Error().stack);
}
and then when it is called it will halt with a stack trace. That can help
figure out what is calling it. (Make sure to build with --profiling so the
stack trace is clear.)
On Mon, Sep 14, 2020 at 7:53 AM 'Sam Clegg' via
On Tue, Sep 1, 2020 at 9:20 AM Prashanth Nethi
wrote:
> That's interesting to know that ALLOW_MEMORY_GROWTH already works with
> PThreads. I will try to do some tests and see how that goes.
>
> Could you tell if there is any performance impact on writing strings
> (using Module._malloc()) or
On Fri, Aug 28, 2020 at 6:17 AM Prashanth Nethi
wrote:
> Thanks for the information Alon! That is exactly the information I wanted.
> Your theory of deferred memory usage pattern might be the reason for
> browsers reporting used memory differently.
>
> It is unfortunate that we will not be able
On Thu, Aug 27, 2020 at 10:28 AM Prashanth Nethi
wrote:
> My bad Alon! I will try to elaborate the scenario.I am trying to
> understand the implications of switching off ALLOW_MEMORY_GROWTH in our
> project. (which would be the case if we want PTHREADS enabled).
>
> The question is around, what
On Thu, Aug 27, 2020 at 8:47 AM Prashanth Nethi
wrote:
> Thanks Alon! That explains it! Yeah I should have thought a little deeper.
>
> I am just posting my follow up question in case you did not get a chance
> to look at it.
>
> One follow up question. May be a dumb one. What could be the
There isn't an option for that. You might try to modify emcc.py to make it
not call binaryen. I think that could work - but you'd get a much less
optimized wasm, which on a project of that size could be a problem.
It's probably best to build binaryen manually - it's much simpler and
smaller than
My guess is that's because of the behavior of std::vector and how it
resizes. Over those appends it will malloc and free repeatedly and that may
cause fragmentation that prevents a final larger size, which must be a
single contiguous region. The second version allocates many smaller ones,
not a
I think you can do any number up to 2GB, including 2GB - 64Kb. So the limit
isn't 1GB, unless you see that on some specific browser? Could be a bug.
It should soon be possible to do up to 4GB for the initial memory (without
growth), thanks to a spec change,
I believe this is from 1.39.16, the changelog entry (
https://github.com/emscripten-core/emscripten/blob/master/ChangeLog.md#13916-05152020)
says
Change the factory function created by using the MODULARIZE build option to
return a Promise instead of the module instance. That is, beforehand
C-7 Shlomi Fish wrote:
>
>> On Wed, 19 Aug 2020 08:25:26 -0700
>> Alon Zakai wrote:
>>
>> > Hi everyone,
>> >
>> > Last week we released Emscripten 2.0.0. That's a big milestone as it's
>> the
>> > first version to not support the o
Hi everyone,
Last week we released Emscripten 2.0.0. That's a big milestone as it's the
first version to not support the old fastcomp backend anymore,
https://github.com/emscripten-core/emscripten/issues/11319
You can still use it by using an older version (the last to support
fastcomp is
What is the error?
If it's COOP/COEP-related, then you need to set up your webserver properly,
https://web.dev/coop-coep/
Here is how the test suite does it:
https://github.com/emscripten-core/emscripten/blob/a85b3038738e8f027cf4acad6e272e8c3321ce3f/tests/runner.py#L1370
On Fri, Aug 7, 2020
We don't have CI tests for pointerlock, so it's possible something
regressed. It would be great if someone has time to look into puppeteer or
another test framework that supports that.
I'd suggest bisecting to find when that happened. If it regressed, we
should add a test to
I think this is
https://github.com/emscripten-core/emscripten/issues/11771
Sorry about this regression - please use the previous release until we tag
a new one with a fix.
On Fri, Jul 31, 2020 at 1:50 PM キャロウ マーク wrote:
> When compiling my project with emcc 1.40 we get the following errors
Standalone mode will require WASI if it does things like logging. Wasm by
itself doesn't have an API for that, so we need *something*, and we try to
use standard APIs as much as possible (see
https://v8.dev/blog/emscripten-standalone-wasm#let's-unify-as-much-as-possible
).
That is, if you see
Interesting, so this can use pthreads from the main thread ok, but not when
starting from a pthread?
That is a less-tested use case, so it's possible you've run into a bug.
Building with -s PTHREADS_DEBUG may help with extra logging. But it may be
best to try to reduce this to a small testcase,
This is a good question, and I'm curious to see what people suggest, but I
see you posted the same question both here and on github - let's please
continue the discussion there, so that the conversation isn't split between
two places,
https://github.com/emscripten-core/emscripten/issues/11700
In
I believe we have tests for this, so one option is to look there (grepping
for `getenv()` in tests/, etc.).
But it is possible there is a bug here. So also worth doing is trying to
make a small testcase showing where preRun fails to work as you expect.
That might either show a bug, or help
t when newlines are met, they are removed
>> before the string is handed to the js app. This seems like an error. The js
>> app receiving the text cannot know if this particular string should be with
>> or without newline as the framework deletes the newline.
>>
>>
&
> It seems the printf output is made more responsive by sending data to the
> JS-print method every time \n (10) or 0 (string termination) is found,
> which is great (if it preserves all characters, including \n, which it
> doesn't seem to). Could we make it operate using a smaller buffer o
One possible noticeable difference with a normal target is that we print
using console.log() and other JS APIs, which can't print partial lines -
they always add a newline. So we buffer, and call those APIs only when we
reach a newline. As a result, you won't see partial lines printed until a
oper who uses a variety of computers to work, I personally would
> appreciate the performance improvements and the energy savings of making
> one build per release per platform and distributing the appropriate ones
> for direct use with no additional compilation stage.
>
> -- brion
' via emscripten-discuss <
emscripten-discuss@googlegroups.com> wrote:
> How does the wasm2c build work with something as large as LLVM? I would
> assume that at some point the C file would get so large that the C compiler
> would fall over.
>
> On Thu, Jul 9, 2020 at 12:58
At the risk of sounding like a broken record - I've been talking about the
next idea a lot recently ;) - I think this is something wasm2c can help
with. I just gave a talk about how:
http://kripken.github.io/talks/2020/universal.html#/
The idea is that we add a single additional build target,
2020, at 15:59, Alon Zakai wrote:
> >
> > Embind and the WebIDL binder are separate tools. They don't have any
> special support for mixing between them.
>
> That’s what I had concluded. Thanks for confirming. My confusion arose
> because it is not clear (to me at lea
Embind and the WebIDL binder are separate tools. They don't have any
special support for mixing between them.
The WebIDL binder doesn't have direct support for copying data from JS into
wasm. You can do it manually though, without the WebIDL binder, by
malloc()ing some room, copying the data (all
Perhaps we should rename emscripten/math.h to emscripten/em_math.h, or
something else? It seems risky to leave as it is.
On Thu, Jun 18, 2020 at 7:33 AM Brian Gavin wrote:
> I was using 'system/include/emscripten' as an include path so I removed
> it, but I am still seeing the same errors.
>
>
Ok, looks like 2 weeks and no concerns here, so I think we are ready to
move forward on removing fastcomp.
I'll post in that issue with the concrete next steps, please follow there
if you're interested.
On Tue, Jun 2, 2020 at 4:03 PM Alon Zakai wrote:
> Hi everyone,
>
> As the new
No, that error cannot be caused by something like TOTAL_MEMORY.
That it works fine if you disable the cache proves what the issue is:
something to do with the network. Specifically, maybe the cache has bad
data, or isn't working properly.
Another thing to try is to see what happens on multiple
"expected X bytes, fell off end" means that the wasm file is truncated - it
stops too early. Perhaps only part of it was downloaded before the server
stopped for some reason. The problem is likely your webserver, or the
network connection.
Here is where V8 emits that message:
In that case, I think you may need to set MAXIMUM_MEMORY to 4GB, or to -1,
so that it is compatible with your manually-created memory.
What I think might have changed here is that emscripten now sets the
default MAXIMUM_MEMORY to 2GB. That is because not all VMs support 4GB yet,
and also since to
> WebAssembly.instantiate(): memory import 51 has no maximum limit,
expected at most 4294967295
Aside from memory growth, what compiler flags are you using for
INITIAL_MEMORY and MAXIMUM_MEMORY? And are you creating the memory yourself?
But I'm not sure what causes that error: "no limit" seems
(I think you mean 11030, and not 1130?)
That would be great Punit!
The fetch code is in src/Fetch.js. Looking for onsuccess in that file is
probably the fastest way to find the relevant code.
To get started you might want to first create a testcase that fails, so
that you can see that it works
Hi everyone,
As the new upstream backend has been the default for a long time, we would
like to start planning the removal of the old fastcomp backend. See full
details of what that means here:
https://github.com/emscripten-core/emscripten/issues/11319
Please let us know if there are any
This will affect all browsers eventually, as it is the agreed direction in
the standards bodies.
I'm not an expert on COOP/COEP, but I don't think you need to build the
module differently. You may need to change the webserver's responses,
though. See for example what our browser test suite does,
Nice!
I think it would be useful to have examples like this in the main docs, or
linked from them.
Perhaps open a PR with a link to this, and we can discuss further there?
On Sat, May 30, 2020 at 7:12 AM Brian Gavin wrote:
> Hello I have created an example of how to have Emscripten run with
We don't run tests on our CI using the SpiderMonkey shell (but we do test
Firefox in the browser suite), so perhaps we need to add something in
src/shell.js for it.
Our CI shell tests mostly run in node, with a few using d8 when we test
very new wasm features not yet in node.
The current status
1 - 100 of 1716 matches
Mail list logo
