-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
windows: crash using net with nvidia software firewall #3404
Labels
Comments
karaziox, Your program runs fine for me: C:\a\code\src\a>go run network.go &{200 OK 200 HTTP/1.1 1 1 map[Expires:[-1] P3p:[CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."] Date:[Wed, 28 Mar 2012 00:43:29 GMT] X-Xss-Protection:[1; mode=block] Set-Cookie:[PREF=ID=2a25e4e4ee59e831:FF=0:TM=1332895409:LM=1332895409:S=n38x2_bB6YIBDdNj; expires=Fri, 28-Mar-2014 00:43:29 GMT; path=/; domain=.google.com.au NID=58=P-3WZsQ13sis9CeioN58XuVFe8um2lBSZnVRe7YVceeEn2_xGo33q6b20F0rta4nnjaY7kCqaHhxOox8RaOxwO0fgap2ovQEONAd6m3RVUx94xwwi2iDk7buopDzw3VN; expires=Thu, 27-Sep-2012 00:43:29 GMT; path=/; domain=.google.com.au; HttpOnly] X-Frame-Options:[SAMEORIGIN] Content-Type:[text/html; charset=ISO-8859-1] Server:[gws] Cache-Control:[private, max-age=0]] 0xf840088d80 -1 [chunked] false map[] 0xf84007a0c0} <nil> Here is my go version and environment: C:\a\code\src\a>go version go version weekly.2012-03-22 +f5fbf05c731c C:\a\code\src\a>go env set GOROOT=c:\mingw64\go set GOBIN=c:\mingw64\go\bin set GOARCH=amd64 set GOCHAR=6 set GOOS=windows set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOTOOLDIR=c:\mingw64\go\pkg\tool\windows_amd64 set GOGCCFLAGS=-g -O2 -m64 -mthreads set CGO_ENABLED=1 Please, show us your version and environment. Go programs when they crash are suppose to print failure details to the console (stderr). No such luck with your program. Trying to understand why, I find this in one of your reported files: <ProblemSignatures> <EventType>BEX64</EventType> <Parameter0>a.out.exe</Parameter0> <Parameter1>0.0.0.0</Parameter1> <Parameter2>4f711908</Parameter2> <Parameter3>nvLsp64.dll</Parameter3> <Parameter4>2.2.0.7325</Parameter4> <Parameter5>4b582375</Parameter5> <Parameter6>0000000000003395</Parameter6> <Parameter7>c0000005</Parameter7> <Parameter8>00000000badc0de1</Parameter8> </ProblemSignatures> So, your program had "memory access failure" c0000005 (reading memory at address that does not exist or something similar). It has happened while it was running inside nvLsp64.dll. We do not use such dll. So, you system loaded this dll into your process for some unknown to us reason. Looking on the web, http://www.freefixer.com/library/file/56871/ is appears to be "NVIDIA Application Filter", whatever that means. This dll could be installing its own "exception handler" on top of Go "exception handler" and, when crashes, never calls us, but instead failing to the system handler. That is why you do not see nice Go stack trace. You could try to see if you could build an exe that can be executed somewhere else - on the other computer. Just build exe: go build -o network.exe network.go and run network.exe on different computer. If it works as expected, then try some simpler program package main func main() { println("hello") } if that runs on your computer. I do not know what in our Go executable tickles problem in your nvLsp64.dll. I am not sure how far you are prepared to go to find. But please, report your findings so far and we could decide then. Thank you. Alex Labels changed: added os-windows. Owner changed to @alexbrainman. |
Ok, I just tried building network.go on my computer and running it on my laptop (Also a Windows 7 x64) and the program executed without any problem. Here is the output of go env: set GOROOT=C:\go set GOBIN=C:\go\bin set GOARCH=amd64 set GOCHAR=6 set GOOS=windows set GOEXE=.exe set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOTOOLDIR=C:\go\pkg\tool\windows_amd64 set GOGCCFLAGS=-g -O2 -m64 -mthreads and go version : go version weekly.2012-03-22 I already has some go programs running on this computer, so far the only case when the program crash is when it use network (The godoc server crash, a program with mymysql driver crash too. But some simple sorting algorithms run without problems) I'll check on my side for nvLsp64.dll, my motherboard chipset is a nVidia nForce so the ddl is probably some driver part related to network, I'll take a look and keep you informed |
It is a good to know, that at least you can successfully build programs that runs somewhere else. And that you can run "some" programs. What is important for us is to see the stack trace at the moment of crash. To know which of our system calls tickles your problem. Then we could decide where the problem is. Unfortunately, we do not get stack trace printed, so, perhaps, you could try and find it yourself. It is not easy, but I use print statements to ensure progress in my program. It might get lower level, so you would have to use a debugger. gdb or http://www.ollydbg.de/version2.html might help. Do you have issues with other programs on your computer? Perhaps, your driver is buggy and there is an update for it? Alex |
Ok, I'm not pretty sure what I was doing with gdb (Never used before) but just running network.exe and showing a backtrace when it hits the SIGSEGV give me this : #0 0x0000000180003395 in ?? () from D:\Program Files\NVIDIA Corporation\NetworkAccessManager\bin32\nvLsp64.dll Cannot access memory at address 0x5bd00 I also unplugged my network cable and tried using my second network card (pci card) to acces internet but the problem remain (nvLsp64.dll segfault) I don't really know how to operate gdb so if you need something more precise just ask. |
I am not much good with this myself :-). This might be helpful: http://golang.org/doc/debugging_with_gdb.html. You could try to do "bt" (show stack command) in gdb once it hits SIGSEGV, to see if you can gather where it stopped (who called who). Alex |
Also, please, change your program to package main import ( "net/http" "fmt" ) func main() { fmt.Println("Hello") resp, err := http.Get("http://google.com") fmt.Println(resp) fmt.Println(err) } and tell us, if you could see "Hello" printed before your program crashes or not. Thank you. Alex |
Yes, I can see the hello before the segfault but the two lines I pasted on the last comment was the output of bt #0 0x0000000180003395 in ?? () from D:\Program Files\NVIDIA Corporation\NetworkAccessManager\bin32\nvLsp64.dll Cannot access memory at address 0x5bd00 I'll continue looking with gdb for the last syscall |
I just managed to get the last lines executed before the segfault. Here is the backtrace for the last line before the crash: #0 syscall.Syscall (fn=void, nargs=void, a1=void, r1=void, r2=void, err=void) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/runtime/syscall_windows.goc:1701 #1 0x00000000004c85ac in syscall.socket (af=2, typ=1, protocol=0, handle=void, err=...) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/syscall/zsyscall_windows_amd64.go:1201 #2 0x00000000004c53a1 in syscall.Socket (domain=2, typ=1, proto=0, fd=5679648, err=...) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/syscall/syscall_windows.go:554 #3 0x000000000049e168 in net.socket (net=..., f=2, t=1, p=0, ipv6only=false, la=..., ra=..., toAddr= {void (syscall.Sockaddr, net.Addr *)} 0x3d41830, fd=0x49a9d0, err=...) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/net/sock.go:22 #4 0x000000000049bfdb in net.internetSocket (net=..., laddr=..., raddr=..., sotype=1, proto=0, mode=..., toAddr= {void (syscall.Sockaddr, net.Addr *)} 0x3d418e0, fd=0x3d41980, err=...) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/net/ipsock_posix.go:138 #5 0x00000000004a0e41 in net.DialTCP (net=..., laddr=0x0, raddr=0xf840051e20, noname=void) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/net/tcpsock_posix.go:243 #6 0x00000000004921da in net.dialAddr (net=..., addr=..., addri=..., c=..., err=...) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/net/dial.go:102 #7 0x0000000000491f8f in net.Dial (net=..., addr=..., noname=void) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/net/dial.go:96 I also have no active firewall on my computer (So the nvidia forceware probably act at lower level. I have no interface or anything concerning a firewall in my nvidia panel) |
Ok, I don't know what append but now I receive two other signals before the segfault Here are the two: (gdb) s [New Thread 4484.0x8bc] Program received signal SIGINT, Interrupt. [Switching to Thread 4484.0x8bc] 0x00000000779846d2 in KERNEL32!CtrlRoutine () from C:\Windows\system32\kernel32.dll (gdb) bt #0 0x00000000779846d2 in KERNEL32!CtrlRoutine () from C:\Windows\system32\kernel32.dll #1 0x0000000000000000 in ?? () And the second : (gdb) s Single stepping until exit from function KERNEL32!CtrlRoutine, which has no line number information. Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 4484.0x1b8c] 0x0000000000417e7c in syscall.Syscall (fn=void, nargs=void, a1=void, r1=void, r2=void, err=void) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/runtime/syscall_windows.goc:1701 1701 C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist234079826/go/src/pkg/runtime/syscall_windows.goc: No such file or directory. |
I did just read that the nVidia Forceware network thing is only an optional part coming with the drivers, after unistalling I tried the sample program and it ran as expected. Since nVidia stopped making chipset and that this part is optional, the chances this error happen again to another user is thin. If you still want to check why this crash happen, just ask and I will reinstall the firewall for testing :) Thanks for your help |
karaziox, Good detective work :-) #1 0x00000000004c85ac in syscall.socket (af=2, typ=1, protocol=0, handle=void, err=...) means socket(AF_INET, SOCK_STREAM, 0) (http://goo.gl/G1cMu), which looks normal to me. I am sure many other programs on your computer issue calls like that and they do not crash. It must be something else that tickle that bug in nvLsp64.dll. It is not easy to debug someone else program. Espesialy if you do not have source code for it. It is certainly doable, but I have very little expirience. Luckily, you could get rid of the program. Hopefully, I would not need your help with that in the future :-) But thank you for offer. Alex Status changed to Retracted. |
Starting program: e:\code\go\hello\src\cstring.exe [New Thread 9740.0x258c] [New Thread 9740.0x1b28] hello from C! Program received signal SIGSEGV, Segmentation fault. runtime.asmcgocall (fn=can't compute CFA for this frame ) at C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist309699735/go/src/pkg/runtim e/asm_amd64.s:462 462 C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist309699735/go/src/pkg/runti me/asm_amd64.s: No such file or directory. in C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist309699735/go/src/pkg/ru ntime/asm_amd64.s (gdb) |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Attachments:
The text was updated successfully, but these errors were encountered: