Comment 1:

You indicated that you are using gccgo.  Are you sure?  gccgo does not support Windows.

Comment 2:

My understanding was that it would use that under the hood.  Forgive me if that is
incorrect, I'm still new around here.  I'm specifying nothing in particular in regards
to what compiler or linker to use.  I'm running go build / go install / go run, with
nothing special specified.
For gcc, I'm using wingw_w64 if that helps.

Comment 3:

perhaps we can adjust the issue report template to ask:
which command line do you use to build the program (go build, 6g, etc)?
which operating system are you using (including architecture [386/amd64/arm]; for Unix,
please include the result of running 'uname -a')?
with the introduction of the go command, the user sometimes doesn't know which compiler
he is using, and arguably,  he shouldn't care in normal cases.
for the OS part, maybe we can just ask for output of 'go env' (plus 'uname -a' if on
Unix).

Comment 4:

I'd be happy to provide whatever would be most helpful and try any suggestions to do
something differently.
Since you mentioned it, here's my go env:
set GOROOT=E:\Applications\Go
set GOBIN=
set GOARCH=amd64
set GOCHAR=6
set GOOS=windows
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOTOOLDIR=E:\Applications\Go\pkg\tool\windows_amd64
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CGO_ENABLED=1

Comment 5:

Can you tell us more about "crash". What exactly do you see? Thank you.
Alex

Comment 6:

I'm not in front of my computer right now, so I can't be very specific.  After printing
the string to stdout, it "stops responding" (windows term). Windows then attempts its
typical phone home for a solution. Once that is finished or cancelled, the terminal
prints a negative exit code. I don't recall if it is a different code each time or not.
I'll comment when I can run it again.

Comment 7:

Here is the full output I'm seeing.
hello from C!
exit status -1073741819

Comment 8:

-1073741819 is -3FFFFFFB in hex is 5 (ERROR_ACCESS_DENIED). I wonder who returns this
error code and why? Please tell us, how did you build the program, step by step? How do
you run it?
Also, when you see "typical phone home for a solution" dialogue, is there any useful for
us information displayed? Just tell us everything you see there however insignificant.
Sometimes, Windows will create "a crash error file", if one is created, just open it
with your editor and send us the contents.
Also, there were some changes to cgo on windows that are not part of 1.0.2. Perhaps, you
can try latest version possible. Just follow http://golang.org/doc/install/source to get
source, but use "tip". Since you are building cgo program, I assume you already have gcc
installed, so the rest should be easy enough.
Thank you.
Alex

Comment 9:

I have the code saved as cstring.go.  I've run with:
$> go run cstring.go
or
$> go build cstring.go
and run the .exe
Both result in the same behavior.
WERDataCollectionFailure.txt contains:
DefaultDataCollection failed: 0x8007012b
appcompat.txt contains:
<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="a.out.exe" FILTER="CMI_FILTER_PRIVACY">
    <MATCHING_FILE NAME="a.out.exe" SIZE="388096" CHECKSUM="0xFF82DBE0" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x10000" LINK_DATE="08/13/2012 11:14:17" UPTO_LINK_DATE="08/13/2012 11:14:17" EXPORT_NAME="C:\Users\Adam\AppData\Local\Temp\go-build525906171\command-line-arguments\_obj\a.out.exe" EXE_WRAPPER="0x0" />
</EXE>
<EXE NAME="a.out.exe" FILTER="CMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="a.out.exe" SIZE="388096" CHECKSUM="0xFF82DBE0" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x10000" LINK_DATE="08/13/2012 11:14:17" UPTO_LINK_DATE="08/13/2012 11:14:17" EXPORT_NAME="C:\Users\Adam\AppData\Local\Temp\go-build525906171\command-line-arguments\_obj\a.out.exe" EXE_WRAPPER="0x0" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="CMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="kernel32.dll" SIZE="1162752" CHECKSUM="0x38678646" BIN_FILE_VERSION="6.1.7601.17651" BIN_PRODUCT_VERSION="6.1.7601.17651" PRODUCT_VERSION="6.1.7600.16385" FILE_DESCRIPTION="Windows NT BASE API Client DLL" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Microsoft® Windows® Operating System" FILE_VERSION="6.1.7600.16385 (win7_rtm.090713-1255)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. All rights reserved." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x12386D" LINKER_VERSION="0x60001" UPTO_BIN_FILE_VERSION="6.1.7601.17651" UPTO_BIN_PRODUCT_VERSION="6.1.7601.17651" LINK_DATE="07/16/2011 05:27:23" UPTO_LINK_DATE="07/16/2011 05:27:23" EXPORT_NAME="KERNEL32.dll" VER_LANGUAGE="English (United States) [0x409]" EXE_WRAPPER="0x0" FILE_ID="0000ade184001d3b1d5cb68c5922428c6148303b63cd" PROGRAM_ID="0000f519feec486de87ed73cb92d3cac802400000000" />
</EXE>
</DATABASE>
WERInternalMetadata.xml contains:
<?xml version="1.0" encoding="UTF-16"?>
<WERReportMetadata>
    <OSVersionInformation>
        <WindowsNTVersion>6.1</WindowsNTVersion>
        <Build>7601 Service Pack 1</Build>
        <Product>(0x30): Windows 7 Professional</Product>
        <Edition>Professional</Edition>
        <BuildString>7601.17835.amd64fre.win7sp1_gdr.120503-2030</BuildString>
        <Revision>1130</Revision>
        <Flavor>Multiprocessor Free</Flavor>
        <Architecture>X64</Architecture>
        <LCID>1033</LCID>
    </OSVersionInformation>
    <ParentProcessInformation>
        <ParentProcessId>5600</ParentProcessId>
        <ParentProcessPath>E:\Applications\Go\bin\go.exe</ParentProcessPath>
        <ParentProcessCmdLine>go  run cstring.go</ParentProcessCmdLine>
    </ParentProcessInformation>
    <ProblemSignatures>
        <EventType>BEX64</EventType>
        <Parameter0>a.out.exe</Parameter0>
        <Parameter1>0.0.0.0</Parameter1>
        <Parameter2>5028e189</Parameter2>
        <Parameter3>a.out.exe</Parameter3>
        <Parameter4>0.0.0.0</Parameter4>
        <Parameter5>5028e189</Parameter5>
        <Parameter6>00000000000123c7</Parameter6>
        <Parameter7>c0000005</Parameter7>
        <Parameter8>00000000badc0de1</Parameter8>
    </ProblemSignatures>
    <DynamicSignatures>
        <Parameter1>6.1.7601.2.1.0.256.48</Parameter1>
        <Parameter2>1033</Parameter2>
        <Parameter22>c055</Parameter22>
        <Parameter23>c055ba8a8a6bb9a80f00d2b6ae2a194e</Parameter23>
        <Parameter24>21ac</Parameter24>
        <Parameter25>21ac5551b6d4ee442965ba60df9a30f4</Parameter25>
    </DynamicSignatures>
    <SystemInformation>
        <MID>761705F2-F166-467D-A645-3525CBF625A3</MID>
        <SystemManufacturer>System manufacturer</SystemManufacturer>
        <SystemProductName>System Product Name</SystemProductName>
        <BIOSVersion>0704</BIOSVersion>
    </SystemInformation>
</WERReportMetadata>

Comment 10:

I won't be able to try the changes in 'tip' until tonight.  I'll comment again after I
do so.

Comment 11:

I just tested against tip and receive the same results.  Although, I did notice that if
I run via: go run cstring.go I see the exit status for the ERROR_ACCESS_DENIED (the same
number as before).  But if I first run: go build cstring.go and run the generated exe,
The exit status is not printed to the terminal.  It still seems to crash in the same
manner, just no exit status is printed.

Comment 12:

Thank you for you report. Unfortunately I do not have any new/better ideas about your
problem. 
Please, do not use "go run ...", but just run your built program directly.
I was expecting that using "tip" Go version will produce nice stack trace when you run
your program, but you say that it still produces "phone home for a solution" dialogue.
Or well. Perhaps, you can run your program under gdb and get stack trace this way.
http://golang.org/doc/gdb could be helpful.
What you see looks similar to https://golang.org/issue/3404, but the
reason for failure is, obviously, very different.
Alex

Comment 13:

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)

Comment 14:

And in case it's useful:
Dump of assembler code for function runtime.asmcgocall:
   0x000000000041235a <+0>:     mov    0x8(%rsp),%rax
   0x000000000041235f <+5>:     mov    0x10(%rsp),%rbx
   0x0000000000412364 <+10>:    mov    %rsp,%rdx
   0x0000000000412367 <+13>:    mov    %gs:0x28,%rcx
   0x0000000000412370 <+22>:    mov    0x8(%rcx),%rbp
   0x0000000000412374 <+26>:    mov    0x0(%rbp),%rsi
   0x0000000000412378 <+30>:    mov    (%rcx),%rdi
   0x000000000041237b <+33>:    cmp    %rdi,%rsi
   0x000000000041237e <+36>:    je     0x412397 <runtime.asmcgocall+61>
   0x0000000000412380 <+38>:    mov    %rsp,0x20(%rdi)
   0x0000000000412384 <+42>:    movq   $0x412359,0x28(%rdi)
   0x000000000041238c <+50>:    mov    %rdi,0x30(%rdi)
   0x0000000000412390 <+54>:    mov    %rsi,(%rcx)
   0x0000000000412393 <+57>:    mov    0x20(%rsi),%rsp
   0x0000000000412397 <+61>:    sub    $0x30,%rsp
   0x000000000041239b <+65>:    and    $0xfffffffffffffff0,%rsp
   0x000000000041239f <+69>:    mov    %rdi,0x20(%rsp)
   0x00000000004123a4 <+74>:    mov    %rdx,0x18(%rsp)
   0x00000000004123a9 <+79>:    mov    %rbx,%rdi
   0x00000000004123ac <+82>:    mov    %rbx,%rcx
   0x00000000004123af <+85>:    callq  *%rax
   0x00000000004123b1 <+87>:    mov    %gs:0x28,%rcx
   0x00000000004123ba <+96>:    mov    0x20(%rsp),%rdi
   0x00000000004123bf <+101>:   mov    %rdi,(%rcx)
   0x00000000004123c2 <+104>:   mov    0x18(%rsp),%rsp
=> 0x00000000004123c7 <+109>:   retq
End of assembler dump.

Comment 15:

Please, show stack trace ("bt" command when it crashes). Also my line numbers are
different. I wonder what your version of go is - just do "hg id" or "hg par" inside of
$GOROOT.
Alex

Comment 16:

Backtrace right before it crashes.
$> (gdb) bt
#0  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
Cannot access memory at address 0x64
$> hg par
changeset:   13879:3cb4a7a06ab9
tag:         tip
user:        Dmitriy Vyukov <dvyukov@google.com>
date:        Tue Aug 14 01:57:24 2012 +0400
summary:     net: remove unused fields

Comment 17:

I still do not know why it is happening, but I can reproduce it now. It works on 386,
but not on amd64. Thank you for your patience.
Alex

Labels changed: added priority-soon, packagebug, cgo, os-windows, arch-x86-64, removed priority-triage.

Owner changed to @alexbrainman.

Status changed to Accepted.

Comment 18:

Not a problem, thanks for sticking with it.  Let me know if there's anything further I
can do to help.

Comment 19:

Even simpler program
package main
// #include <stdio.h>
//
// void say() {
//    printf("%s from C\n", "hello");
// }
//
import "C"
func main() {
    C.say()
}
fails for me.
Alex

Comment 20:

Confirmed.  Same problem with that one for me as well.

Comment 21:

http://golang.org/cl/6490056/

Status changed to Started.

Comment 22:

This issue was closed by revision 7f075ec.

Status changed to Fixed.

Comment 23:

Issue #3662 has been merged into this issue.