NYUCCL / psiTurk

An open platform for science on Amazon Mechanical Turk.
https://psiturk.org
MIT License
277 stars 140 forks source link

tunnel error with /Users/jaymartin #191

Closed jacob-lee closed 5 years ago

jacob-lee commented 9 years ago

Occasionally I am getting a runtime error using psiturk's tunneling service in the command line tool. I do not know what initiates the error. Here is a portion of the run-time error (it grows indefinitely). Curiously, if I type in another command, e.g. by pressing the up arrow key to use the last command, the error is no longer printed to screen.

I assume that something was hard coded into the source of ngrok

[psiTurk server:on mode:live tunnel:✓ #HITs:1]$ panic: runtime error: invalid memory address or nil pointer dereference [signal 0xb code=0x1 addr=0x20 pc=0x15ae31]

goroutine 630 [running]: runtime.panic(0x3821c0, 0x869bb9) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/runtime/panic.c:266 +0xb6 bytes.(_Buffer).ReadFrom(0xc215464620, 0x0, 0x0, 0x0, 0x0, ...) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/bytes/buffer.go:169 +0x1f1 ngrok/proto.extractBody(0x0, 0x0, 0x0, 0x0, 0x0, ...) /Users/jaymartin/ngrok/src/ngrok/proto/http.go:53 +0x60 ngrok/proto.(_Http).readResponses(0xc21003d540, 0xc215482410, 0xc21542af60) /Users/jaymartin/ngrok/src/ngrok/proto/http.go:114 +0x2aa created by ngrok/proto.(*Http).WrapConn /Users/jaymartin/ngrok/src/ngrok/proto/http.go:63 +0xc3

goroutine 1 [select]: ngrok/client.(*Controller).Run(0xc210050ba0, 0xc21004a3f0) /Users/jaymartin/ngrok/src/ngrok/client/controller.go:194 +0xa57 ngrok/client.Main() /Users/jaymartin/ngrok/src/ngrok/client/main.go:51 +0x258 main.main() /Users/jaymartin/ngrok/src/ngrok/main/ngrok/ngrok.go:8 +0x1a

goroutine 3 [chan receive]: code.google.com/p/log4go.ConsoleLogWriter.run(0xc210071000, 0xc11140, 0xc210000008) /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:27 +0x60 created by code.google.com/p/log4go.NewConsoleLogWriter /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:19 +0x67

goroutine 5 [syscall]: os/signal.loop() /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/signal/signal_unix.go:21 +0x1e created by os/signal.init·1 /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/signal/signal_unix.go:27 +0x31

goroutine 6 [runnable]: code.google.com/p/log4go.ConsoleLogWriter.run(0xc210071580, 0xc11140, 0xc210000008) /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:27 +0x60 created by code.google.com/p/log4go.NewConsoleLogWriter /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:19 +0x67

goroutine 7 [select]: ngrok/util.func·001() /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:20 +0x3ed created by ngrok/util.NewBroadcast /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:42 +0x129

goroutine 8 [select]: ngrok/util.func·001() /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:20 +0x3ed created by ngrok/util.NewBroadcast /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:42 +0x129

goroutine 9 [chan receive]: github.com/rcrowley/go-metrics.(*meterArbiter).tick(0x870b40) /Users/jaymartin/ngrok/src/github.com/rcrowley/go-metrics/meter.go:221 +0x4e created by github.com/rcrowley/go-metrics.NewMeter /Users/jaymartin/ngrok/src/github.com/rcrowley/go-metrics/meter.go:40 +0x1a1

goroutine 10 [select]: ngrok/util.func·001() /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:20 +0x3ed created by ngrok/util.NewBroadcast /Users/jaymartin/ngrok/src/ngrok/util/broadcast.go:42 +0x129

goroutine 11 [IO wait]: net.runtime_pollWait(0xc12d80, 0x72, 0x0) /private/tmp/go-Wayl/go/src/pkg/runtime/netpoll.goc:116 +0x6a net.(_pollDesc).Wait(0xc21004ad10, 0x72, 0xc110c0, 0x23) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/fd_poll_runtime.go:81 +0x34 net.(_pollDesc).WaitRead(0xc21004ad10, 0x23, 0xc110c0) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/fd_poll_runtime.go:86 +0x30 net.(_netFD).accept(0xc21004acb0, 0x4c7d70, 0x0, 0xc110c0, 0x23) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/fd_unix.go:382 +0x2c2 net.(_TCPListener).AcceptTCP(0xc210000680, 0x18, 0xc2100d7838, 0x1dab83) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/tcpsock_posix.go:233 +0x47 net.(_TCPListener).Accept(0xc210000680, 0xc11d60, 0xc2100bbc30, 0x0, 0x0) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/tcpsock_posix.go:243 +0x27 net/http.(_Server).Serve(0xc21009d230, 0xc11db8, 0xc210000680, 0x0, 0x0) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/http/server.go:1622 +0x91 net/http.(_Server).ListenAndServe(0xc21009d230, 0xc21009d230, 0x2800000000) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/http/server.go:1612 +0xa0 net/http.ListenAndServe(0xc210033aa0, 0xe, 0x0, 0x0, 0x2fd10, ...) /usr/local/Cellar/go/1.2.2/libexec/src/pkg/net/http/server.go:1677 +0x6d ngrok/client/views/web.func·009() /Users/jaymartin/ngrok/src/ngrok/client/views/web/view.go:69 +0x39 ngrok/client.func·003() /Users/jaymartin/ngrok/src/ngrok/client/controller.go:96 +0x63 created by ngrok/client.(_Controller).Go /Users/jaymartin/ngrok/src/ngrok/client/controller.go:97 +0x8b

goroutine 12 [chan receive]: ngrok/client/views/web.(_WebHttpView).updateHttp(0xc21009d1e0) /Users/jaymartin/ngrok/src/ngrok/client/views/web/http.go:149 +0xab ngrok/client/views/web._WebHttpView.(ngrok/client/views/web.updateHttp)·fm() /Users/jaymartin/ngrok/src/ngrok/client/views/web/http.go:87 +0x26 ngrok/client.func·003() /Users/jaymartin/ngrok/src/ngrok/client/controller.go:96 +0x63 created by ngrok/client.(*Controller).Go /Users/jaymartin/ngrok/src/ngrok/client/controller.go:97 +0x8b

etc.

dbirman commented 9 years ago

I also got this error today--it crashed my server from the participant's point of view even though the server on my end just continued with no other errors.

dbirman commented 9 years ago

Just occurred again--not sure if it crashed things for participants. Here is the full error:

[psiTurk server:on mode:live tunnel:✓ #HITs:1]$ panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x20 pc=0x15ae31]

goroutine 1174 [running]:
runtime.panic(0x3821c0, 0x869bb9)
    /usr/local/Cellar/go/1.2.2/libexec/src/pkg/runtime/panic.c:266 +0xb6
bytes.(*Buffer).ReadFrom(0xc211466690, 0x0, 0x0, 0x0, 0x0, ...)
    /usr/local/Cellar/go/1.2.2/libexec/src/pkg/bytes/buffer.go:169 +0x1f1
ngrok/proto.extractBody(0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /Users/jaymartin/ngrok/src/ngrok/proto/http.go:53 +0x60
ngrok/proto.(*Http).readRequests(0xc21003f540, 0xc2115e2320, 0xc2115af780, 0x38aee0, 0xc21159b780)
    /Users/jaymartin/ngrok/src/ngrok/proto/http.go:92 +0x2f8
created by ngrok/proto.(*Http).WrapConn
    /Users/jaymartin/ngrok/src/ngrok/proto/http.go:62 +0x98

goroutine 1 [select]:
ngrok/client.(*Controller).Run(0xc21004fba0, 0xc210049380)
    /Users/jaymartin/ngrok/src/ngrok/client/controller.go:194 +0xa57
ngrok/client.Main()
    /Users/jaymartin/ngrok/src/ngrok/client/main.go:51 +0x258
main.main()
    /Users/jaymartin/ngrok/src/ngrok/main/ngrok/ngrok.go:8 +0x1a

goroutine 3 [chan receive]:
code.google.com/p/log4go.ConsoleLogWriter.run(0xc210070000, 0xb11140, 0xc210000008)
    /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:27 +0x60
created by code.google.com/p/log4go.NewConsoleLogWriter
    /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:19 +0x67

goroutine 5 [syscall]:
os/signal.loop()
    /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/signal/signal_unix.go:21 +0x1e
created by os/signal.init·1
    /usr/local/Cellar/go/1.2.2/libexec/src/pkg/os/signal/signal_unix.go:27 +0x31

goroutine 6 [runnable]:
code.google.com/p/log4go.ConsoleLogWriter.run(0xc210070420, 0xb11140, 0xc210000008)
    /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:27 +0x60
created by code.google.com/p/log4go.NewConsoleLogWriter
    /Users/jaymartin/ngrok/src/code.google.com/p/log4go/termlog.go:19 +0x67
dbirman commented 8 years ago

@jacob-lee Were you able to resolve this issue?

@gureckis Any idea what's happening here?

jacob-lee commented 8 years ago

No, I am unable to resolve this issue. I think that the module being called is a pre-compiled binary. The occurrence is sporadic.

On Fri, Oct 23, 2015 at 3:01 PM, Dan Birman notifications@github.com wrote:

@jacob-lee https://github.com/jacob-lee Were you able to resolve this issue?

@gureckis https://github.com/gureckis Any idea what's happening here?

— Reply to this email directly or view it on GitHub https://github.com/NYUCCL/psiTurk/issues/191#issuecomment-150664271.

dbirman commented 8 years ago

I've been debugging this all day and I think it may be related to the tunnel expiring after a certain length of time. Is your task particularly long?

jacob-lee commented 8 years ago

That would make sense in my experience

On Oct 23, 2015, at 4:36 PM, Dan Birman notifications@github.com wrote:

I've been debugging this all day and I think it may be related to the tunnel expiring after a certain length of time. Is your task particularly long?

— Reply to this email directly or view it on GitHub.

gureckis commented 8 years ago

@jbmartin was the main architect of the tunnel and he hasn’t been as active with the project lately (we still basically consider it a “beta” feature).

i do believe there is some type of compiled binary that he made which is distributed in the psiturk egg. this is where the references to his username maybe coming from on your command line.

it is possible there is a time out on the tunnel server side, but i’m not sure…

the hope is to move to a docker style hosted solution soon so that we don’t have to deal with this stuff. may happen relatively soon so stay tuned...

On Oct 23, 2015, at 4:44 PM, jacob-lee notifications@github.com wrote:

That would make sense in my experience

On Oct 23, 2015, at 4:36 PM, Dan Birman notifications@github.com wrote:

I've been debugging this all day and I think it may be related to the tunnel expiring after a certain length of time. Is your task particularly long?

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/NYUCCL/psiTurk/issues/191#issuecomment-150685496.

dbirman commented 8 years ago

Thanks for the response-- After much testing I've figured out this is related to the size of your data objects. We were sending an object that was growing with time and was getting into the multiple MB range after thirty minutes, and removing that data from our save data calls solved the problem for us. Maybe you can add a note to the wiki mentioning that this problem exists?

deargle commented 5 years ago

Tunnel no longer supported