windows programs compiled with cgo do not set exception handler

[LukeMauldin]

What steps will reproduce the problem?
1.  Compile and run the attached code on Windows 7 or Windows Server 2008 R2.
2.  The entire Go process will crash when accessing the URL http://localhost:8181/Test

What is the expected output?
The expected output is that a stack trace will be printed from the panic and that the
goroutine serving the request will fail but that the entire web server process will not
crash.

What do you see instead?
The web server process crashes.

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Tested on Windows 7 X64, Windows Server 2008 R2 and the web server process crashes. 
Tested on Ubuntu X64 and the web server process does not crash and the panic stack trace
is printed correctly.

Which version are you using?  (run 'go version')
go version weekly.2012-03-27 +99292bad0d6d

Please provide any additional information below.
Below is an output from GDB debugging the program on Windows.  As you can see, the first
time the URL was accessed, the program did not crash but correctly printed the stack
trace.  However, the second time the URL was accessed, GDB received 2 seg faults and the
entire program crashed.  The majority of the time the web server process crashes every
time.  
The problem seems to occur less often if I do not import the mgodbc.go file.  Also, I
have been unable to reproduce the problem outside of a web server process.

(gdb) r
Starting program: C:\Users\lmauldin\Documents\Eclipse\TestWebCrash\bin\main.exe

[New Thread 4436.0x25f0]
[New Thread 4436.0x1380]
[New Thread 4436.0x1e24]
[New Thread 4436.0xea0]
[New Thread 4436.0x1c30]

Program received signal SIGSEGV, Segmentation fault.
main.WebTest ()
    at C:/Users/lmauldin/Documents/Eclipse/TestWebCrash/src/main.go:22
22              _ = *s
(gdb) c
Continuing.
[New Thread 4436.0x1844]
2012/04/17 18:24:48 http: panic serving 127.0.0.1:52340: runtime error: invalid
memory address or nil pointer dereference
c:/GoBuild/go/src/pkg/net/http/server.go:576 (0x43f446)
        _func_003: buf.Write(debug.Stack())
c:/GoBuild/go/src/pkg/runtime/proc.c:1443 (0x411086)
        panic: reflect-+call(d->fn, d->args, d->siz);
c:/GoBuild/go/src/pkg/runtime/runtime.c:129 (0x411bee)
        panicstring: runtime-+panic(err);
c:/GoBuild/go/src/pkg/runtime/thread_windows.c:276 (0x414bd5)
        sigpanic: runtime-+panicstring("invalid memory address or nil pointer de
reference");
C:/Users/lmauldin/Documents/Eclipse/TestWebCrash/src/main.go:22 (0x401144)
        WebTest: _ = *s
c:/GoBuild/go/src/pkg/net/http/server.go:690 (0x4333da)
        HandlerFunc.ServeHTTP: f(w, r)
c:/GoBuild/go/src/pkg/net/http/server.go:926 (0x43427d)
        (*ServeMux).ServeHTTP: mux.handler(r).ServeHTTP(w, r)
c:/GoBuild/go/src/pkg/net/http/server.go:656 (0x4331e7)
        (*conn).serve: handler.ServeHTTP(w, w.req)
c:/GoBuild/go/src/pkg/runtime/proc.c:271 (0x40efc2)
        goexit: runtime-+goexit(void)

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 4436.0x1c30]
main.WebTest ()
    at C:/Users/lmauldin/Documents/Eclipse/TestWebCrash/src/main.go:22
22              _ = *s
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
main.WebTest ()
    at C:/Users/lmauldin/Documents/Eclipse/TestWebCrash/src/main.go:22
22              _ = *s
(gdb) c
Continuing.
[Inferior 1 (process 4436) exited with code 030000000005]
(gdb) bt
No stack.
(gdb)

Attachments:

1. main.go (356 bytes)
2. config.go (77 bytes)
3. mgodbc.go (24860 bytes)

[LukeMauldin]

Comment 1:

The gcc version used to build Go:
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/users/lmauldin/downloads/mingw64/bin/../libexec/gcc/x86_6
4-w64-mingw32/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64
-w64-mingw32 --build=x86_64-linux-gnu --target=x86_64-w64-mingw32 --with-sysroot
=/home/ruben/mingw-w64/toolchain/mingw64mingw64/mingw64 --prefix=/home/ruben/min
gw-w64/toolchain/mingw64mingw64/mingw64 --with-libiconv-prefix=/home/ruben/mingw
-w64/toolchain/mingw64mingw64/prereq_install --with-gmp=/home/ruben/mingw-w64/to
olchain/mingw64mingw64/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchai
n/mingw64mingw64/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/mingw
64mingw64/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/mingw64mingw
64/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/mingw64mingw64/pr
ereq_install --enable-cloog-backend=isl --with-host-libstdcxx='-static -lstdc++
-lm' --enable-shared --enable-static --enable-threads=posix --disable-multilib -
-enable-languages=c,lto,c++,objc,obj-c++,fortran,java --enable-libgomp --enable-
libstdcxx-debug --enable-sjlj-exceptions --enable-fully-dynamic-string --disable
-nls --disable-werror --enable-checking=release --disable-win32-registry --disab
le-rpath --disable-werror CFLAGS='-O2 -mtune=corei7 -fomit-frame-pointer -momit-
leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-pa
rallelize-all' LDFLAGS=
Thread model: posix
gcc version 4.7.0 20120311 (prerelease) (GCC)

[LukeMauldin]

Comment 2:

Attached the EXE file built on a clean Windows Server 2008 R2 X64 environment that is
shows the process crash.

Attachments:

1. testwebcrash.exe (3739648 bytes)

[alexbrainman]

Comment 3:

It looks like windows programs compiled with cgo do not set exception handler. Only
first thread has exception handler set, but not others. See simplified version of your
test (thank you) attached. It is an oversight. We will have to fix it.
On unrelated note, I can see that you are using odbc on Windows. You should not need cgo
for that, just call appropriate dlls directly. See http://code.google.com/p/gowingui/
for an example of how to. I, personally, avoid cgo when possible, because you have to
use another extra set of tools (gcc + gcc runtime) and that makes things more
complicated. Also cgo and gcc, as you discovered, are behind comparing to unix platforms.
@rsc:
Exception handlers implementations are very different on amd64 and 386.
On 386 all thread exception handlers are linked into a linked list, and we install ours
by creating appropriate list elements (SEH) on the stack and removing them once we are
done. First thread creates its SEH in _rt0_386_windows (I think it is too early, our
exception handler is not ready to do anything so early). All other non-cgo threads
install and remove its SEH in tstart. Cgo threads do not call tstart, therefore they do
not install SEH.
On amd64 our pe header points to exception handler. The only other thing we need to do
to make exception handler working is to call setstacklimits. This is done in settls
(probably too early too) for first thread, and in tstart_stdcall for other non-cgo
threads. Again cgo threads do not call neither settls nor tstart_stdcall, so no
exception handler for them.
I think correct fix for amd64 is to call setstacklimits from minit instead. 386 fix is
bit more complicated, since SEH is installed and then removed on stack. I can, probably,
create heap storage for SEH data, but, still, it needs to be *removed* after we are done
with our thread so SEH chain remains correct. So single minit is not enough, I need mend
or something for 386.
I do not want to start major renovations, but ... What do you think?
Thank you.
Alex

Labels changed: added os-windows, cgo.

Owner changed to @alexbrainman.

Status changed to Accepted.

Attachments:

1. main.go (559 bytes)
2. mgodbc.go (27 bytes)

[LukeMauldin]

Comment 4:

Thank you for accepting the bug and thank you for pointing me to gowingui.  I looked at
the code and it looks like it is using syscall and a script to generate some proxies:
mksyscall_windows.pl  Is there any documentation on the script and how to use syscall?

[alexbrainman]

Comment 5:

lukemauldin,
What I do, I put special comment starting with \\sys in winapi.go. For example:
//sys GetModuleHandle(modname *uint16) (handle syscall.Handle, err error) =
GetModuleHandleW
Then I run
make zwinapi.go
This command will regenerate zwinapi.go file based on these //sys comments in winapi.go.
zwinapi.go: winapi.go
        (echo '// +build windows'; \
        $(GOROOT)/src/pkg/syscall/mksyscall_windows.pl $<) \
                | gofmt \
                > $@
is the rule in Makefile. So it calls mksyscall_windows.pl to do the work. There are some
comments describing format of //sys lines in mksyscall_windows.pl.
Alternatively look at different //sys lines in winapi.go (and compare them with
generated proxies in zwinapi.go) to get the gist of it. There are many more in
$GOROOT\src\pkg\syscall\syscall_windows.go. You will need a unix computer to do it since
mksyscall_windows.pl is a perl script.
You will also need to translate some consts and structs from C to Go.
All this is manual and bit tedious to do, but once it is done it is done. Also, it is
important, there are no mistakes - arguments / fields have correct types and sizes -
otherwise your program will start crashing without good reason. I hope it is not too
much. If you need any help, just ask. I would do it myself, but I do not have urgent
need to connect to database. And you only find problems with your code when you use it.
Alex

[LukeMauldin]

Comment 6:

Alex,
Thank you very much for the direction.  I used your instructions, along with the wingui
project to create an interface layer to ODBC using entirely syscall and no cgo.  It was
a difficult but rewarding experience and I learned alot.  Once I get the chance to
verify my code a bit more, I plan on posting it to go-lang nuts for a peer review to get
feedback from others.

[LukeMauldin]

Comment 7:

Alex,
I have added my code to github:  https://github.com/LukeMauldin/go-lodbc  
If you get a chance, I would appreciate you glancing over it and providing some feedback
because I am still a relatively new Go programmer.

[alexbrainman]

Comment 8:

http://golang.org/cl/6245063/

Status changed to Started.

[alexbrainman]

Comment 9:

This issue was closed by revision afe0e97.

Status changed to Fixed.