gopherjs: Endless unwinding call stack for seachJsObject
Today while attempting to integrate a test JS wrapper for the cache API released for webkit, a previous compile work but all new compiles consistently errored out due to a stack overflow error. Having established it is not the Go code in question I hoped any could help.
The problem arises when goperhjs attempts to retrieving the functions argument type for a promise, but instead cycles out till stack memory is depleted
WebCache Doc: https://developer.mozilla.org/en-US/docs/Web/API/Cache WebCache API: https://github.com/gu-io/gu/blob/develop/shell/cache/webcache/webcache.go#L62-L66
Example Code:
package main
import (
"honnef.co/go/js/dom"
"github.com/gu-io/gu/shell/cache/webcache"
)
func main() {
doc := dom.GetWindow().Document().(dom.HTMLDocument)
body := doc.QuerySelector("body").(*dom.HTMLBodyElement)
webCache, err := webcache.New()
if err != nil {
body.AppendChild(doc.CreateTextNode(err.Error()))
body.AppendChild(doc.CreateElement("br"))
}
cache, err := webCache.Open("debi.v1") // issue arises here.
if err != nil {
body.AppendChild(doc.CreateTextNode(err.Error() + "\n"))
body.AppendChild(doc.CreateElement("br"))
return
}
err = cache.Add("http://localhost:8080/github.com/gu-io/gu/shell/")
if err != nil {
body.AppendChild(doc.CreateTextNode(err.Error()))
body.AppendChild(doc.CreateElement("br"))
}
res, err := cache.MatchPath("http://localhost:8080/github.com/gu-io/gu/shell/", webcache.MatchAttr{})
if err != nil {
body.AppendChild(doc.CreateTextNode(err.Error()))
body.AppendChild(doc.CreateElement("br"))
return
}
item := doc.CreateElement("div")
item.SetInnerHTML(string(res.Body))
body.AppendChild(item)
body.AppendChild(doc.CreateElement("br"))
}
Error Received:
main.js:2058 Uncaught (in promise) RangeError: Maximum call stack size exceeded
at searchJsObject (main.js:2058)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
//-------------------MORE---OF---THE---SAME--------//
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2067)
at searchJsObject (main.js:2070)
at $internalize (main.js:2081)
at $internalize (main.js:2032)
at v.$externalizeWrapper (main.js:1872)
The above stack trace has been shortened due to its large length.
GoperhJS Code In Question: https://github.com/gopherjs/gopherjs/blob/master/compiler/prelude/jsmapping.go#L343-L371
It seems to be blowing up at the area of retrieving a pointer to the object response when using a promise.
Expected Response:
No SearchJsObject
error when calling a Promise.
Any help would truly be appreciated. I attempted to resolve the issues with some changes to the jsmapping.go
region as linked above but failed, I assumed if we capped the depth since it was causing a repetition of the same t.Fields[0]
and t
pointer then it was properly a cyclical issue, but failed because the object received was not the appropriate *js.Object
pointing to the cache instance. Irony is v
matches the instance of the cache object in JS land but not sure how to resolve the cycle and attached it properly to a pointer in Go land within the jsmapping
, but figuring out a means to stop the recurring call to check the same t
and t.Field[0]
which were the same with each call to searchJSObject
and adequately get this area
var f = t.fields[0];
var o = searchJsObject(f.typ);
if (o !== noJsObject) {
var n = new t.ptr();
n[f.prop] = o;
return n;
}
executed properly seems to be the issue.
Thanks.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 28 (11 by maintainers)
Commits related to this issue
- compiler/typesutil: Detect vendored js package and exit. This follows #538. Vendoring github.com/gopherjs/gopherjs/js package is not supported, and can cause hard to understand runtime errors. Be... — committed to gopherjs/gopherjs by dmitshur 7 years ago
- build: Detect vendored js package and return error. (#572) This follows #538. Vendoring github.com/gopherjs/gopherjs/js package is not supported, and can cause hard to understand runtime errors. ... — committed to gopherjs/gopherjs by dmitshur 7 years ago
Thanks. I can see it happening when I run it with your generated JavaScript:
So it’s not the browser differences, but something about the generated JavaScript output.
I tried
gopherjs build
in that folder too, and the problem continues to occur.I’ll look more into it this evening, but at least I can repro it locally now.
go get -u
I meant.