Comment 1:

Need to revert changes to build.go from http://golang.org/cl/5504062.
Russ, what are the steps to reproduce the problem you have seen? I do not know how to
build misc/cgo/life using "go tool". Were you using windows_amd64 to test? I just fixed
bug (http://golang.org/cl/5500094) in windows_amd64 cgo were g0 stack was not
set properly. Maybe that is what you were seeing.
Alex

Comment 2:

I believe that if you roll back 5504062, any test
using cgo will fail, including the one for package net.

Comment 3:

Yes it does:
--- cd ../misc/cgo/life
rm -rf *.o *.a *.[568vq] [568vq].out life *.so _obj _test _testmain.go *.exe _cgo*
test.out build.out
CGOPKGPATH= cgo --  life.go
touch _obj/_cgo_run
8g   -p life -o _go_.8  _obj/life.cgo1.go _obj/_cgo_gotypes.go
8c -FVw -I/C/MinGW/go/pkg/windows_386 -I . -o "_cgo_defun.8" _obj/_cgo_defun.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_main.o -c   _obj/_cgo_main.c
_obj/_cgo_main.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -g -fPIC -O2 -o c-life.o -c   c-life.c
c-life.c:1:0: warning: -fPIC ignored for target (all code is position independent)
gcc -m32 -I . -g -fPIC -O2 -o life.cgo2.o -c   _obj/life.cgo2.c
_obj/life.cgo2.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -I . -g -fPIC -O2 -o _cgo_export.o -c   _obj/_cgo_export.c
_obj/_cgo_export.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o c-life.o life.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_
_obj/_cgo_import.c
8c -FVw -I . -o "_cgo_import.8" _obj/_cgo_import.c
rm -f _obj/life.a
gopack grc _obj/life.a _go_.8  _cgo_defun.8 _cgo_import.8 c-life.o  life.cgo2.o
_cgo_export.o
cp _obj/life.a "/C/MinGW/go/pkg/windows_386/life.a"
8g   main.go
8l -o life main.8
unexpected fault address 0xffffffff
throw: fault
[signal 0xc0000005 code=0x0 addr=0xffffffff pc=0x4e1594]
goroutine 1 [syscall]:
life._Cfunc_Step(0x10, 0x10)
        c:/MinGW/go/misc/cgo/life/_obj/_cgo_defun.c:45 +0x31
life.Run(0xa, 0x10, 0x10, 0x10e36000, 0x2710, ...)
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-38 +0xa3
main.main()
        c:/MinGW/go/misc/cgo/life/main.go:32 +0x128
goroutine 2 [runnable]:
life._func_001(0x10e2c0f8, 0x10e2c0f0, 0x10e2c0e8, 0x10e2c0e0, 0x10e2c0d8, ...)
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-26
created by life.GoStart
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-26 +0x17c
Thank you, Russ.

Comment 4:

Unless you are hitting a bug in the current code, I am happy
to leave things as they are for now (priority-someday).
Understanding this is not terribly important.
Russ

Comment 6:

Labels changed: added go1.3.

Comment 7:

Labels changed: removed go1.3.

Comment 8:

Labels changed: added repo-main.

Comment 9 by czarek.tomczak:

Hi, I suspect that this bug may be happening to me. Application works fine on both Linux
and OS X. But on Windows I get these "unexpected fault address 0xffffffff" errors. I'm
initializing two structures cef_app_t/cef_client_t and setting methods on them such as
"add_ref" and "release". These methods are later called by external Chromium library.
The error happens after the first call to "add_ref" made by Chromium. In import "C" the
"cef_base.h" is included
(https://github.com/CzarekTomczak/cef2go/blob/master/handlers/cef_base.h#L59) which sets
these methods.
Is there any fix for this that I could apply on my own?

Comment 10:

The "unexpected fault address 0xffffffff" error message means you are trying to access
something at address 0xffffffff. It is too general. It does not have to be related to
this issue.
Alex

Comment 11 by czarek.tomczak:

@comment #10 alex.bra...@gmail.com
But this same code runs perfectly fine on Linux and OS X. It is the same code for all
platforms. It happens only when calling C code from an .h file that is included using
import "C" (link in comment #9). How can I debug such error?

Comment 12:

... How can I debug such error?
Give the steps to reproduce the error, I will try and look into it. I suggest you start
new issue. If we find both issues are the same, we can always merge them later.
Alex

Comment 13 by czarek.tomczak:

Alex, I've debugged this further. It turns out this is some problem with GCC on Windows
when calling Chromium C API, as I've prepared a C example that does same things as in Go
and these exceptions also occur. Sorry for off-topic here.

Comment 14:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

I've reverted CL 5504062 and this issue does not reproduce anymore. I'm on Windows 11 using Mingw-w64 11.2.0 and Go tip.