peterh / liner

Pure Go line editor with history, inspired by linenoise
MIT License
1.05k stars 132 forks source link

Exception generated intermittently by using Prompt #50

Closed neitzj closed 8 years ago

neitzj commented 9 years ago

Hi we are making use of your liner library in a command line tool we are working. We have noticed that we are getting intermittent crashes with the following stack trace. I was hoping you might be able to shed some light on the problem. Thanks.

pureweb >Exception 0xc0000005 0x1 0xc082063988 0x7720c4d0 PC=0x7720c4d0 signal arrived during cgo execution

syscall.(_Proc).Call(0xc08208bf20, 0xc0820479c0, 0x4, 0x4, 0x1, 0x0, 0x0, 0x0) c:/go/src/syscall/dll_windows.go:136 +0x5c2 syscall.(_LazyProc).Call(0xc082005ef0, 0xc0820479c0, 0x4, 0x4, 0x1, 0x0, 0x0, 0x 0) c:/go/src/syscall/dll_windows.go:279 +0x74 github.com/peterh/liner.(_State).readNext(0xc0820680a0, 0x0, 0x0, 0x0, 0x0) E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/github.com/peterh/liner/inp ut_windows.go:160 +0x182 github.com/peterh/liner.(_State).Prompt(0xc0820680a0, 0x7787b0, 0x9, 0x0, 0x0, 0 x0, 0x0) E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/github.com/peterh/liner/lin e.go:492 +0x358 github.com/gobs/cmd.(*Cmd).CmdLoop(0xc082068000) E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/github.com/gobs/cmd/cmd.go: 564 +0xb1 main.main() E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/calgaryscientific.com/purew eb-cli/main.go:70 +0xaaa

goroutine 5 [syscall, 1110 minutes]: os/signal.loop() c:/go/src/os/signal/signal_unix.go:21 +0x26 created by os/signal.init-+1 c:/go/src/os/signal/signal_unix.go:27 +0x3c

goroutine 13 [chan receive, 1110 minutes]: main.func-+001() E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/calgaryscientific.com/purew eb-cli/main.go:57 +0x74 created by main.main E:/bamboobuilds/PWEB-PMGN-WIN/src/gocode/src/calgaryscientific.com/purew eb-cli/main.go:62 +0xa30

goroutine 56 [IO wait, 127 minutes]: net.(_pollDesc).Wait(0xc08207a170, 0x72, 0x0, 0x0) c:/go/src/net/fd_poll_runtime.go:84 +0x4e net.(_ioSrv).ExecIO(0xc082040148, 0xc08207a060, 0x75a5b0, 0x7, 0x7f8090, 0x0, 0x 0, 0x0) c:/go/src/net/fd_windows.go:188 +0x305 net.(_netFD).Read(0xc08207a000, 0xc082011000, 0x1000, 0x1000, 0x0, 0x0, 0x0) c:/go/src/net/fd_windows.go:470 +0x180 net.(_conn).Read(0xc082040168, 0xc082011000, 0x1000, 0x1000, 0x0, 0x0, 0x0) c:/go/src/net/net.go:121 +0xe3 net/http.noteEOFReader.Read(0x283998, 0xc082040168, 0xc082028058, 0xc082011000, 0x1000, 0x1000, 0x6bb9a0, 0x0, 0x0) c:/go/src/net/http/transport.go:1270 +0x75 net/http.(_noteEOFReader).Read(0xc082007480, 0xc082011000, 0x1000, 0x1000, 0xc08 2012000, 0x0, 0x0)

:125 +0xdb bufio.(_Reader).fill(0xc082042de0) c:/go/src/bufio/bufio.go:97 +0x1d5 bufio.(_Reader).Peek(0xc082042de0, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0) c:/go/src/bufio/bufio.go:132 +0xf7 net/http.(_persistConn).readLoop(0xc082028000) c:/go/src/net/http/transport.go:842 +0xab created by net/http.(*Transport).dialConn c:/go/src/net/http/transport.go:660 +0xca6 goroutine 57 [select, 127 minutes]: net/http.(_persistConn).writeLoop(0xc082028000) c:/go/src/net/http/transport.go:945 +0x424 created by net/http.(_Transport).dialConn c:/go/src/net/http/transport.go:661 +0xcc3 rax 0x1 rbx 0x1 rcx 0x7746ddda rdx 0x0 rdi 0x0 rsi 0x0 rbp 0x8f8820 rsp 0x6fcd0 r8 0x6fc98 r9 0x8f8820 r10 0x0 r11 0x246 r12 0xc082063988 r13 0xc0820639ac r14 0x20 r15 0x10 rip 0x7720c4d0 rflags 0x10246 cs 0x33 fs 0x53 gs 0x2b
peterh commented 9 years ago

I've never seen that particular crash before. What version of Windows, what version of Go?

I've got two theories, neither one of which is particularly likely:

  1. https://support.microsoft.com/en-us/kb/2458000
  2. Go 1.5 (I'm still using 1.4.2 on windows) has improved escape analysis, and the garbage collector thinks it can move &input and &rv (in input_windows.go) during the system call.

The first one should be easy to test by installing the hotfix. The second one is slightly trickier to test; the Go runtime doesn't have a way to pin memory, so the long-term fix probably involves calls to HeapAlloc.

peterh commented 9 years ago

I just updated to Go 1.5 on one of my Windows machines, and I haven't been able to reproduce the issue with a simple test case. Do you have a complete standalone program that reproduces the crash?

neitzj commented 9 years ago

Hi Peter

We are using go 1.4.2, windows 7

We can't currently upgrade 1.4.2 at this time. We can't reliably reproduce the problem it appears to happen some what randomly either right away or after many hours of use.

We have a small console program that makes use of a modified version of this library https://github.com/gobs/cmd. Which internally calls liner. Their example calls Prompt just like we are. After that you can interact with the prompt and after some time we get the stack trace I posted in this initial issue.

peterh commented 9 years ago

How long is "some time"? Are there particular commands that trigger the stack trace? I just spent a few minutes feeding your example garbage input, and I haven't seen a stack trace yet.

neitzj commented 9 years ago

A long time can be somewhere around 12 hours of idleness then enter a normal command and boom. This happens during normal use of defined commands. It seems to happen once we finish with a command and it returns to the prompt.

Like I said we don't have a particular use case to reproduce this.

peterh commented 9 years ago

Please try the new "heap" branch and let me know if it fixes the issue.

peterh commented 9 years ago

@neitzj Ping?

peterh commented 9 years ago

@neitzj I just noticed that I missed a file when pushing the heap branch. I've just force-pushed a corrected version. Please give it a try and let me know if it fixes the bug: afde681d6a6cb609d0e1714fb89d892a4e83f434

neitzj commented 9 years ago

Peter. Hi I was away on vacation. I will pull the heap branch and give this a try. Thanks for your help.

On Mon, Oct 5, 2015 at 8:08 AM, Peter Harris notifications@github.com wrote:

@neitzj https://github.com/neitzj I just noticed that I missed a file when pushing the heap branch. I've just force-pushed a corrected version. Please give it a try and let me know if it fixes the bug: afde681 https://github.com/peterh/liner/commit/afde681d6a6cb609d0e1714fb89d892a4e83f434

— Reply to this email directly or view it on GitHub https://github.com/peterh/liner/issues/50#issuecomment-145539282.

Jonathan Neitz Senior Software Developer, Calgary Scientific Inc.

Suite 208, 1210 – 20th Ave SE Calgary AB T2G 1M8 Canada

Mountain Daylight Time (GMT – 6:00)

Office: *+1 403 270 7159 <%2B1%C2%A0403%20270%207159>*

Fax: *+1 403 270 2771 <%2B1%C2%A0403%20270%202771>*

web: http://www.calgaryscientific.com http://www.calgaryscientific.com/ Email: jonathan.neitz@calgaryscientific.com jonathan.neitz@calgaryscientific.com


If you believe you have received this electronic transmission in error, please notify the original sender of this email and destroy all copies of this communication.

peterh commented 8 years ago

@neitzj Ping?

peterh commented 8 years ago

No response for months. I've never been able to reproduce this. All usages in liner conform to the most recently published guidelines (C never holds onto a pointer, and there are no pointers embedded in any memory passed to C).

Therefore, I presume this was caused by something else. Please re-open if you have more evidence.

prattmic commented 2 years ago

FWIW, I encountered a similar looking crash to this in delve: https://github.com/go-delve/delve/issues/2869.

peterh commented 2 years ago

Possibly fixed by 8b893efac17e49ccf0bee5a5a805497cc3edc072