Comment 1:

Thanks for the report.  It's too late for us to fix this for Go 1 but we will look into
it after that.

Labels changed: added priority-later, removed priority-triage.

Status changed to Accepted.

Comment 2:

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.

Comment 3:

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

Comment 4:

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

Comment 5:

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.

Comment 6:

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

Comment 7:

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

Comment 8:

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

Comment 9:

The "Nvidia (Forceware) Network Access Manager" is a software firewall for Windows.
It is easy to believe that it doesn't like something about the way Go uses the network,
which is probably different from MSVC-compiled programs.

Labels changed: added expertneeded.

Comment 10:

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)

Comment 11:

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.

Comment 12:

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

Comment 13:

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.

Comment 14:

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)