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.
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
x/crypto/ssh: test consistently runs out of memory on js-wasm builder #32840
Comments
The code is allocating memory in a tight loop. Somehow the wasm runtime is unable to schedule a GC run since it runs on a single thread. Although I believe this is a valid bug with wasm runtime (I have seen this happen once to someone in gophers slack), but for now, adding this patch fixes it - diff --git a/ssh/handshake_test.go b/ssh/handshake_test.go
index 91d4935..742678a 100644
--- a/ssh/handshake_test.go
+++ b/ssh/handshake_test.go
@@ -455,6 +455,9 @@ func testHandshakeErrorHandlingN(t *testing.T, readLimit, writeLimit int, couple
if err != nil {
break
}
+ if runtime.GOOS == "js" && i%10 == 0 {
+ runtime.GC()
+ }
}
wg.Done()
c.Close() Perhaps we can file an issue and add this patch for now, pointing to the issue. EDIT: or maybe even track this issue for it. |
the explicit GC call is kludge. As kludges go, I prefer to simply t.Skip() on wasm because it is more explicit. |
SGTM. |
Change https://golang.org/cl/184397 mentions this issue: |
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
I think this is a bug in the test itself, not a bug in the As far as I can tell, the calls to I suspect that the explicit call to If this diagnosis is correct, then an appropriate fix may be to bound |
I had thought about that. If that is so, shouldn't it fail in amd64 with Yes, it is a scheduling issue. |
I don't actually know, but in general the set of preemption points is different across different My best guess (and, to be clear, it's only a guess) is that on |
Right, and when I said it's a bug in wasm runtime, I meant for something in cc @neelance for some thoughts. |
I guess the problem is the unlimited write in https://go.googlesource.com/crypto/+/22d7a77e9e5f409e934ed268692e56707cd169e5/ssh/handshake_test.go#452 ? you could try to substitute -1 for writeLimit with a large number (100 would probably do the trick) and see if that works better. |
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
This is correct. Preemption of goroutines requires that the |
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The wasm runtime cannot schedule a GC run on tight loops. Therefore it runs out of memory if such a loop allocates memory. Skip such a test for now. Updates golang/go#32840 Change-Id: I922b6e02710915776d2820573fd1584a5941185b Reviewed-on: https://go-review.googlesource.com/c/crypto/+/184397 Run-TryBot: Agniva De Sarker <agniva.quicksilver@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Han-Wen Nienhuys <hanwen@google.com>
The
golang.org/x/crypto/ssh
test consistently fails on thejs-wasm
builder with the error messageruntime: out of memory: cannot allocate 8192-byte block
.Can the test be made to fit within the runtime on that architecture? If not, it should be skipped, instead of continuing to fail and potentially masking more serious problems.
CC @hanwen @neelance @FiloSottile
The text was updated successfully, but these errors were encountered: