Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: panic opening c-shared DLL on windows #26084

Closed
akamajoris opened this issue Jun 27, 2018 · 5 comments
Closed

cmd/link: panic opening c-shared DLL on windows #26084

akamajoris opened this issue Jun 27, 2018 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Milestone

Comments

@akamajoris
Copy link

akamajoris commented Jun 27, 2018

What version of Go are you using (go version)?

go version go1.11beta1 linux/amd64

Does this issue reproduce with the latest release?

idk

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/root/Desktop/gopath/"
GOPROXY=""
GORACE=""
GOROOT="/root/sdk/go1.11beta1"
GOTMPDIR=""
GOTOOLDIR="/root/sdk/go1.11beta1/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build339636739=/tmp/go-build -gno-record-gcc-switches"
VGOMODROOT=""

What did you do?

loader.go:

package main
import (
	"fmt"
	"syscall"
)
func main() {
	var mod = syscall.NewLazyDLL("main.dll")
	var proc = mod.NewProc("Test")
	x0, x2, x3 := proc.Call()
	fmt.Println( x0, x2, x3)
}

main.go:

package main
import (
	"time"
	"fmt"
)

import "C"

func main(){
}

//export Test
func Test() {
    print("this is a test\n")
    time.Sleep(time.Second *2)
    fmt.Println("222222222222222\n")
}

Building:
GOOS=windows GOARCH=386 CGO_ENABLED=1 CC=i686-w64-mingw32-gcc go11 build -buildmode=c-shared -o main.dll main.go

What did you expect to see?

loader.exe

this is a test
[sleep]
222222222222222

What did you see instead?

loader.exe

this is a test
[sleep]


panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x1 addr=0x0 pc=0x6ab435d4]

goroutine 1 [running]:
syscall.getprocaddress(0x73eb0000, 0x4306e010, 0x0, 0x0)
        /root/sdk/go1.11beta1/src/runtime/syscall_windows.go:154 +0xc9
syscall.(*DLL).FindProc(0x43048000, 0x6abf33d8, 0xd, 0x0, 0x43072000, 0x6ac6a660)
        /root/sdk/go1.11beta1/src/syscall/dll_windows.go:89 +0x54
syscall.(*LazyProc).Find(0x43040d20, 0x0, 0x0)
        /root/sdk/go1.11beta1/src/syscall/dll_windows.go:264 +0xd4
syscall.(*LazyProc).mustFind(0x43040d20)
        /root/sdk/go1.11beta1/src/syscall/dll_windows.go:278 +0x21
syscall.(*LazyProc).Addr(0x43040d20, 0x6ab74219)
        /root/sdk/go1.11beta1/src/syscall/dll_windows.go:287 +0x21
syscall.WriteConsole(0x50, 0x43072000, 0x11, 0x12c7b8a8, 0x0, 0x11, 0x0)
        /root/sdk/go1.11beta1/src/syscall/zsyscall_windows.go:1297 +0x27
internal/poll.(*FD).writeConsole(0x43064160, 0x43070000, 0x11, 0x20, 0x10, 0x43070000, 0x43060114)
        /root/sdk/go1.11beta1/src/internal/poll/fd_windows.go:702 +0x2f6
internal/poll.(*FD).Write(0x43064160, 0x43070000, 0x11, 0x20, 0x0, 0x0, 0x0)
        /root/sdk/go1.11beta1/src/internal/poll/fd_windows.go:649 +0xed
os.(*File).write(0x430420d0, 0x43070000, 0x11, 0x20, 0x10, 0x11, 0x43070000)
        /root/sdk/go1.11beta1/src/os/file_windows.go:223 +0x3d
os.(*File).Write(0x430420d0, 0x43070000, 0x11, 0x20, 0x2, 0x50c6a0, 0x12c4c000)
        /root/sdk/go1.11beta1/src/os/file.go:145 +0x51
fmt.Fprintln(0x6ac062f0, 0x430420d0, 0x12c7bdd8, 0x1, 0x1, 0x12c4c000, 0x6ac6ac60, 0x6ac6ac60)
        /root/sdk/go1.11beta1/src/fmt/print.go:255 +0x6a
fmt.Println(0x12c7bdd8, 0x1, 0x1, 0x12c4c044, 0x12c4c0b4, 0x12c6a034)
        /root/sdk/go1.11beta1/src/fmt/print.go:264 +0x45
main.Test()
        /root/Desktop/gopath/src/dl/main.go:17 +0x89
main._cgoexpwrap_0bacd9f47ac1_Test()
        _cgo_gotypes.go:45 +0x17
runtime: unexpected return pc for runtime.cgocallback_gofunc called from 0x446a1c
stack: frame={sp:0x12c7be64, fp:0x12c7be74} stack=[0x12c74000,0x12c7c000)
12c7bde4:  6ab86390 <runtime.call16+48>  00000004  43034000  00000001
12c7bdf4:  12c7be00  6ab438d7 <runtime.cgocallbackg1+343>  00000000  000dfe48
12c7be04:  000dfe9b  00000000  00000000  6e69616d
12c7be14:  6c6c642e  6ab6c4a3 <runtime.exitsyscall+355>  01c4c000  00000003
12c7be24:  00000002  12c4c000  12c4c000  6ab43703 <runtime.cgocallbackg+179>
12c7be34:  00000000  00000000  004025f5  00000000
12c7be44:  00000000  00000000  00000000  00000000
12c7be54:  00000000  12c7be78  12c4c000  6ab8751e <runtime.cgocallback_gofunc+126>
12c7be64: <00000000  0050c6a0  00447c30 !00446a1c
12c7be74: >00402609  00447c30  0050c8a8  12c48008
12c7be84:  00000400  0050c6a0  00000010  0043a80f
12c7be94:  00447c30  0050c8a8  00000000  0050c6a0
12c7bea4:  004541a1  6abbb510  00000000  00000000
12c7beb4:  00000000  00000000  00000004  0040cf9c
12c7bec4:  00000010  0049aa80  00000001  004243c2
12c7bed4:  00453fdc  0049aa80  12c320f0  6abbb510
12c7bee4:  00000000  00000000  00000000  6abbb510

@akamajoris akamajoris changed the title go1.11beta1: c-shared for windows go1.11beta1: c-shared for windows [runtime error] Jun 27, 2018
@ianlancetaylor ianlancetaylor changed the title go1.11beta1: c-shared for windows [runtime error] cmd/link: panic opening c-shared DLL on windows Jun 27, 2018
@ianlancetaylor ianlancetaylor added OS-Windows NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jun 27, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Jun 27, 2018
@ianlancetaylor
Copy link
Contributor

Does that work with 1.10?

It's odd to use -buildmode=c-shared, which is designed for producing a DLL written in Go to be opened by a C program, and then open the DLL from a Go program. But I guess I don't know why it wouldn't work on Windows.

CC @nadiasvertex

@nadiasvertex
Copy link
Contributor

I'm pretty sure that won't work because the C DLL is getting a copy of the Go runtime embedded in it. The Go runtime does some stuff with thread local storage. So the DLL's copy of the runtime is going to fight with the process's version of the runtime. I think we talked about this in some other thread in the context of Go "plugins".

@akamajoris
Copy link
Author

akamajoris commented Jun 28, 2018

I have tested go1.10.1. Results after execution of loader.exe (compiled by go11):

Starting Up
fatal error: notesleep - waitm out of sync

runtime stack:
runtime.throw(0x6abe7486, 0x1d)
        /usr/lib/go-1.10/src/runtime/panic.go:616 +0x6b
runtime.notesleep(0x50d754)
        /usr/lib/go-1.10/src/runtime/lock_sema.go:160 +0x11e
runtime.stoplockedm()
        /usr/lib/go-1.10/src/runtime/proc.go:2101 +0x79
runtime.schedule()
        /usr/lib/go-1.10/src/runtime/proc.go:2493 +0x27e
runtime.park_m(0x12a4c000)
        /usr/lib/go-1.10/src/runtime/proc.go:2604 +0x9f
runtime.mcall(0x7730a210)
        /usr/lib/go-1.10/src/runtime/asm_386.s:406 +0x47

goroutine 1 [runnable, locked to thread]:
time.init()
        /usr/lib/go-1.10/src/time/zoneinfo_abbrs_windows.go:15 +0x333

P.S.
godll

dllexports

All runtime funtions are exported. Is that fine?

@alexbrainman
Copy link
Member

Is this duplicate of #22192 ?

All runtime funtions are exported. Is that fine?

Looks silly, but I don't think it matters. Does it matter to your case?

Alex

@ianlancetaylor
Copy link
Contributor

Closing as dup of #22192.

@golang golang locked and limited conversation to collaborators Jun 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Windows
Projects
None yet
Development

No branches or pull requests

5 participants