Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

as crash when try to alloc large data #2827

Open
HerrCai0907 opened this issue Mar 18, 2024 · 2 comments · May be fixed by #2831
Open

as crash when try to alloc large data #2827

HerrCai0907 opened this issue Mar 18, 2024 · 2 comments · May be fixed by #2831
Assignees
@CountBleck
Labels
bug

Comments

@HerrCai0907
Copy link
Member

Bug description

AS compiler crash after hang up a few second.

Steps to reproduce

memory.data(0x7fffffff);

npm run asbuild:debug

AssemblyScript version

v0.27.x
@CountBleck CountBleck self-assigned this Mar 18, 2024
@CountBleck
Copy link
Member

It looks like most of the time is spent in the allocU8Array call here, but the exception (a simple number, like 2153016872) is thrown in the binaryen._BinaryenSetMemory call without any delay there. I'll look into it a bit more.

@CountBleck
Copy link
Member

Hm, I can only guess that it has something to do with the copy here, since binaryen.js's memory might hit the 4 GiB limit there.

CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Mar 25, 2024
@CountBleck
Do not allocate MemorySegments for memory.data(i32, i32?)
373166c 
Instead of allocating a MemorySegment, the code now simply bumps the
Compiler's memoryOffset.

Fixes AssemblyScript#2827.
@CountBleck CountBleck linked a pull request Mar 25, 2024 that will close this issue
Open
2 tasks
CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Mar 25, 2024
@CountBleck
Do not allocate buffers for memory.data(i32, i32?)
6a89a09 
MemorySegments can now hold null buffers, which signifies that memory is
in fact used in the compiled program, for programs that only reserve
zero-filled memories. Using null buffers avoids passing zero-filled
buffers to Binaryen, which isn't necessary since Wasm memories are
initialized with zeroes when a (data ...) segment isn't present.

Fixes AssemblyScript#2827.
CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Apr 3, 2024
@CountBleck
fix: Do not allocate buffers for memory.data(i32, i32?)
559814d 
MemorySegments can now hold null buffers, which signifies that memory is
in fact used in the compiled program, for programs that only reserve
zero-filled memories. Using null buffers avoids passing zero-filled
buffers to Binaryen, which isn't necessary since Wasm memories are
initialized with zeroes when a (data ...) segment isn't present.

Fixes AssemblyScript#2827.
CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Apr 3, 2024
@CountBleck
BREAKING CHANGE: Do not allocate buffers for memory.data(i32, i32?)
ed50aef 
MemorySegments can now hold null buffers, which signifies that memory is
in fact used in the compiled program, for programs that only reserve
zero-filled memories. Using null buffers avoids passing zero-filled
buffers to Binaryen, which isn't necessary since Wasm memories are
initialized with zeroes when a (data ...) segment isn't present.

This change is breaking in that modules using imported memories that
contain non-zero values in such memory ranges at the time of
instantiation will retain those values, as opposed to being filled.

Fixes AssemblyScript#2827.
CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Apr 3, 2024
@CountBleck
BREAKING CHANGE: Do not allocate buffers for memory.data(i32, i32?)
4465767 
MemorySegments can now hold null buffers, which signifies that memory is
in fact used in the compiled program, for programs that only reserve
zero-filled memories. Using null buffers avoids passing zero-filled
buffers to Binaryen, which isn't necessary since Wasm memories are
initialized with zeroes when a (data ...) segment isn't present.

This change is breaking in that modules using imported memories that
contain non-zero values in such memory ranges at the time of
instantiation will retain those values, as opposed to being filled.
This shouldn't affect most users, however.

Fixes AssemblyScript#2827.
CountBleck added a commit to CountBleck/assemblyscript that referenced this issue Apr 3, 2024
@CountBleck
BREAKING CHANGE: Do not allocate buffers for memory.data(i32, i32?)
163a631 
MemorySegments can now hold null buffers, which signifies that memory is
in fact used in the compiled program, for programs that only reserve
zero-filled memories. Using null buffers avoids passing zero-filled
buffers to Binaryen, which isn't necessary since Wasm memories are
initialized with zeroes when a (data ...) segment isn't present.

This change is breaking in that modules using imported memories that
contain non-zero values in such memory ranges at the time of
instantiation will retain those values, as opposed to being filled.
This shouldn't affect most users, however, and it could possibly be
desirable.

Fixes AssemblyScript#2827.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@CountBleck CountBleck

Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Do not allocate MemorySegments for memory.data(i32, i32?) CountBleck/assemblyscript
2 participants
@HerrCai0907 @CountBleck