fatal error: invalid stack pointerの原因

 エラー原因

Windows APIにおいて使われるHANDLEは、Windows Data Typesによるとvoid *として定義されています。このvoid *はGoではunsafe.Pointerに相当し、ポインタとして扱われます。しかし、Windows APIが返す実際の値は、ある特定のデータを指すポインタではなく、Handle TableというHandleを管理するテーブルのインデックスになっています。

ここで、runtime.GC()によってGCを実行すると、開放すべきオブジェクトを探すためにポインタならばその先をたどる必要があります。ところがHANDLEの中身は有効なアドレスではありません。この結果エラーが出ているようです。

参考に、HANDLEを返すWindows APIを使って、質問文よりももっと短いプログラムで同じようなエラーが再現できます。
再現プログラム

package main

import (
    "fmt"
    "log"
    "runtime"
)

/*
#include <windows.h>
HANDLE getMailslot() {
    return CreateMailslot("\\\\.\\mailslot\\mailslotname", 0, 0, NULL);
}
*/
import "C"

func main() {
    m, err := C.getMailslot()
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("before: ", m)
    runtime.GC()
    fmt.Println("after: ", m)
}

エラー出力

before:  0x198
runtime: bad pointer in frame main.main at 0xc082031e90: 0x198
fatal error: invalid stack pointer

runtime stack:
runtime.throw(0x52da20, 0x15)
    C:/Go/src/runtime/panic.go:530 +0x97 fp=0x7ef680 sp=0x7ef668
runtime.adjustpointers(0xc082031e90, 0x7ef800, 0x7efb28, 0x554568)
    C:/Go/src/runtime/stack.go:579 +0x2e2 fp=0x7ef778 sp=0x7ef680
runtime.adjustframe(0x7efa48, 0x7efb28, 0x7ef801)
    C:/Go/src/runtime/stack.go:644 +0x1d2 fp=0x7ef838 sp=0x7ef778
runtime.gentraceback(0x453af0, 0xc082031c08, 0x0, 0xc08201c000, 0x0, 0x0, 0x7fffffff, 0x546f08, 0x7efb28, 0x0, ...)
    C:/Go/src/runtime/traceback.go:369 +0xda3 fp=0x7efaa0 sp=0x7ef838
runtime.copystack(0xc08201c000, 0x2000)
    C:/Go/src/runtime/stack.go:759 +0x1c5 fp=0x7efc90 sp=0x7efaa0
runtime.shrinkstack(0xc08201c000)
    C:/Go/src/runtime/stack.go:1026 +0x170 fp=0x7efcc0 sp=0x7efc90
runtime.markroot(0x5)
    C:/Go/src/runtime/mgcmark.go:155 +0x2d2 fp=0x7efd50 sp=0x7efcc0
runtime.gcDrain(0x7efdc0, 0x0)
    C:/Go/src/runtime/mgcmark.go:812 +0x24f fp=0x7efd88 sp=0x7efd50
runtime.gcMark(0xdd715aff0e34)
    C:/Go/src/runtime/mgc.go:1559 +0x100 fp=0x7efde8 sp=0x7efd88
runtime.gcMarkTermination.func1()
    C:/Go/src/runtime/mgc.go:1173 +0x2a fp=0x7efdf8 sp=0x7efde8
runtime.systemstack(0x5a9e00)
    C:/Go/src/runtime/asm_amd64.s:291 +0x7e fp=0x7efe00 sp=0x7efdf8
runtime.mstart()
    C:/Go/src/runtime/proc.go:1048 fp=0x7efe08 sp=0x7efe00

goroutine 1 [copystack]:
runtime.systemstack_switch()
    C:/Go/src/runtime/asm_amd64.s:245 fp=0xc082031c10 sp=0xc082031c08
runtime.gcMarkTermination()
    C:/Go/src/runtime/mgc.go:1181 +0x14b fp=0xc082031e20 sp=0xc082031c10
runtime.gcStart(0x2, 0xc082026000)
    C:/Go/src/runtime/mgc.go:1017 +0x3b5 fp=0xc082031e48 sp=0xc082031e20
runtime.GC()
    C:/Go/src/runtime/mgc.go:840 +0x2c fp=0xc082031e60 sp=0xc082031e48
main.main()
    C:/dev/sample/main.go:23 +0x22d fp=0xc082031f40 sp=0xc082031e60
runtime.main()
    C:/Go/src/runtime/proc.go:188 +0x27e fp=0xc082031f90 sp=0xc082031f40
runtime.goexit()
    C:/Go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc082031f98 sp=0xc082031f90

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    C:/Go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc082025fa8 sp=0xc082025fa0

goroutine 2 [force gc (idle)]:
runtime.gopark(0x547160, 0x5a98f0, 0x51a050, 0xf, 0x14, 0x1)
    C:/Go/src/runtime/proc.go:262 +0x17c fp=0xc082023f38 sp=0xc082023f10
runtime.goparkunlock(0x5a98f0, 0x51a050, 0xf, 0xc08201c014, 0x1)
    C:/Go/src/runtime/proc.go:268 +0x5b fp=0xc082023f70 sp=0xc082023f38
runtime.forcegchelper()
    C:/Go/src/runtime/proc.go:229 +0xc6 fp=0xc082023fa0 sp=0xc082023f70
runtime.goexit()
    C:/Go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc082023fa8 sp=0xc082023fa0
created by runtime.init.4
    C:/Go/src/runtime/proc.go:218 +0x32

goroutine 3 [GC sweep wait]:
runtime.gopark(0x547160, 0x5a9a00, 0x5181d0, 0xd, 0x41d614, 0x1)
    C:/Go/src/runtime/proc.go:262 +0x17c fp=0xc08201ff28 sp=0xc08201ff00
runtime.goparkunlock(0x5a9a00, 0x5181d0, 0xd, 0x14, 0x1)
    C:/Go/src/runtime/proc.go:268 +0x5b fp=0xc08201ff60 sp=0xc08201ff28
runtime.bgsweep(0xc082032000)
    C:/Go/src/runtime/mgcsweep.go:63 +0xbf fp=0xc08201ff98 sp=0xc08201ff60
runtime.goexit()
    C:/Go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc08201ffa0 sp=0xc08201ff98
created by runtime.gcenable
    C:/Go/src/runtime/mgc.go:191 +0x5a

goroutine 4 [finalizer wait]:
runtime.gopark(0x547160, 0x5c3e08, 0x519db0, 0xe, 0x14, 0x1)
    C:/Go/src/runtime/proc.go:262 +0x17c fp=0xc082021ef8 sp=0xc082021ed0
runtime.goparkunlock(0x5c3e08, 0x519db0, 0xe, 0x14, 0x1)
    C:/Go/src/runtime/proc.go:268 +0x5b fp=0xc082021f30 sp=0xc082021ef8
runtime.runfinq()
    C:/Go/src/runtime/mfinal.go:158 +0xb8 fp=0xc082021fa0 sp=0xc082021f30
runtime.goexit()
    C:/Go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc082021fa8 sp=0xc082021fa0
created by runtime.createfing
    C:/Go/src/runtime/mfinal.go:139 +0x67
exit status 2

 解決策

このようなHANDLEを扱うCの関数を扱いたい場合は、Go側でポインタとして扱われてしまうHANDLEではなく、ハンドルの中身の整数値を直接扱うようにすると良いです。例えば、質問文中のプログラムを参考にするならば、HANDLEを返す/受け取る関数をラップし、GoではHANDLEではなくuintptr_tを返す/受け取る関数を使います。

@@ -10,6 +10,12 @@
 #cgo LDFLAGS: -L. -lproprietarydll
 #cgo CFLAGS: -I .
 #include "proprietarydll.h"
+uintptr_t _funcB() {
+    return (uintptr_t)funcB();
+}
+uintptr_t _funcC(uintptr_t ptr) {
+    return (uintptr_t)funcC((HANDLE)ptr));
+}
 */
 import "C"

@@ -18,8 +24,8 @@
         log.Fatal(err)
     }

-    handleB, err := C.funcB()
-    if handleB == nil || err != nil {
+    handleB, err := C._funcB()
+    if handleB == 0 || err != nil {
         if err != nil {
             log.Fatal(err)
         }
@@ -29,14 +35,14 @@
     runtime.GC() // <- cause no error
     fmt.Println("after:\tGC(funcB)", handleB)

-    handleC, err := C.funcC(handleB)
-    if handleC == nil || err != nil {
+    handleC, err := C._funcC(handleB)
+    if handleC == 0 || err != nil {
         if err != nil {
             log.Fatal("handleC is nil")
         }
         return
     }
     fmt.Println("before:\tGC(funcC)", handleC)
-    runtime.GC() // <- ここはエラーが出る
+    runtime.GC() // <- もうエラーが出ない
     fmt.Println("after:\tGC(funcC)", handleC)
 }

 自己解決に至るまで

上述のように、HANDLEがポインタではあるものの、Handle Tableのインデックスを表しているという点について知らなかったことが今回のエラー原因でした。この事について自力で気づけなかった私は、（マルチポストは避けるべきだとは認識しておりましたが、投稿日からの経過日数と閲覧数からもはや回答は得られないのではと思っていたという言い訳をしつつ）本家に問い合わせました。golang/Go#Issue 15794

この結果以下の様な回答をいただきました。

• Windows APIはたとえHANDLEがポインタであったとしても、一般に小さな整数値を返す
• Goのランタイムはポインタとして宣言されているものはポインタとして扱うので、有効なポインタでなければクラッシュする 
• したがって、HANDLEはGoでは(ポインタそのままの)unsafe.Pointerではなく、uintptrとして扱う必要がある

本回答の解決策に載せたプログラムは、本家の方から頂いたこの回答を元に作成したものです。

また、頂いた回答を元に、そもそもHANDLEとは何かについて下記のリンク等を参考にした結果、HANDLEが表すものはHandle Tableのインデックスであり、特定のデータを指す有効なアドレスになっていない（ためエラーが出ていた）という今回の回答に行き着きました。

• Windows の限界に挑む: ハンドル
• What is a Windows Handle?
• pointer vs handles in C (are the terms used to convey separate things?)