cmd/cgo: signal arrived during external code execution that calls setjmp on Windows

[redstorm-fyy]

Processor Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
OS: Windows 7 64
golang:1.5.2
gcc:mingw-w64 version 5.2.0 x86_64-posix-seh-rt_v4-rev1

When I compile golang with some external c code which using the setjmp and longjmp,the program crash.

My c code is here (It's in a c file in a directory which implements package lua)

#include <stdio.h>
#include <setjmp.h>
void Print(){
    jmp_buf c;
    if(setjmp(c)==0){
        longjmp(c,1);
    }
    else{
        printf("receive an exception\n");
    }
}

My go code

package main
import "github.com/redstorm-fyy/go-lua/lua"
func main() {
    lua.Print()
}

Important!
It crashes when the c code is in an external file.When the c code is just up the .go file's import "C",It does not crash.

Crash information
Exception 0xc0000028 0x0 0x0 0x77b096f8
PC=0x77b096f8
signal arrived during external code execution

github.com/redstorm-fyy/go-lua/lua._Cfunc_Print()
??:0 +0x38
github.com/redstorm-fyy/go-lua/lua.Print()
E:/GolangRoot/src/github.com/redstorm-fyy/go-lua/lua/luago.go:587 +0x1b
main.main()
E:/GolangRoot/src/github.com/redstorm-fyy/go-lua/example/exam.go:6 +0x1b

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
c:/go/src/runtime/asm_amd64.s:1721 +0x1
rax 0xf
rbx 0xc0000028
rcx 0x22ebd0
rdi 0x22c000
rsi 0x22f7b0
rbp 0x22f230
rsp 0x22eb10
r8 0x0
r9 0x400000
r10 0x0
r11 0x22f330
r12 0x22fe60
r13 0x22fdb0
r14 0x4013e8
r15 0x584024
rip 0x77b096f8
rflags 0x202
cs 0x33
fs 0x53
gs 0x2b

[ianlancetaylor]

Looks a lot like #9754.

Any chance you can write a standalone test case that does not involve using Lua?

[minux]

I assumed the OP meant this code:

package main
/*
#include <stdio.h>
#include <setjmp.h>
void Print() {
jmp_buf c;
if (setjmp(c) == 0)
longjmp(c,1);
else
printf("receive an exception\n");
}
*/
import "C"
func main() {
C.Print()
}

will panic on windows.

I tried to reproduce it on windows/amd64, external linking works,
but internal linker fails.

C:\go\src>..\bin\go run -ldflags "-linkmode internal" x.go
Exception 0xc0000005 0x8 0xfffffffff9058d48 0xfffffffff9058d48
PC=0xfffffffff9058d48
signal arrived during external code execution

main._Cfunc_Print()
command-line-arguments/_obj/_cgo_gotypes.go:43 +0x38
main.main()
x.go:19 +0x1b

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
C:/go/src/runtime/asm_amd64.s:1998 +0x1

rax 0x459466
rbx 0xc082027f38
rcx 0x22fdd0
rdi 0xc082027f38
rsi 0x4c4c00
rbp 0x22fed0
rsp 0x22fda8
r8 0x45941a
r9 0xc082027ee0
r10 0x11
r11 0x0
r12 0x5
r13 0x4957a5
r14 0x1
r15 0x8
rip 0xfffffffff9058d48
rflags 0x10246
cs 0x33
fs 0x53
gs 0x2b
exit status 2

I'm not convinced that we need to fix internal linking as external linking
is the default now.

[ianlancetaylor]

If I'm reading this right, the problem is that cmd/link is not generating the correct exception information for the Windows OS. Is that correct?

[minux]

Does setjmp/longjmp require exception information? The code doesn't actually raise any exception, it basically, setjmp and then immediately longjmp.

[ianlancetaylor]

It seems pretty clear from the error message that some exception is occurring.

This MSDN page implies that longjmp is exception aware: https://msdn.microsoft.com/en-us/library/yz2ez4as.aspx .

[minux]

The problem turns out to be incorrect relocation by the internal linker. mingw gcc generates a wrapper for longjmp. objdump -d _all.o has this: 0000000000000076 <longjmp>: 76: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 7d <longjmp+0x7> 79: R_X86_64_PC32 __imp_longjmp 7d: ff 20 jmpq *(%rax) 7f: 90 nop But the final linked executable contains code like this: 0000000000459436 <longjmp>: 459436: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 459436 <longjmp> 45943d: ff 20 jmpq *(%rax) 45943f: 90 Which is obviously incorrect.

[rsc]

cmd/link/internal/amd64/asm.go seems to want to reject this case:

case 256 + ld.R_X86_64_PC32:
    if targ.Type == obj.SDYNIMPORT {
        ld.Diag("unexpected R_X86_64_PC32 relocation for dynamic symbol %s", targ.Name)
    }
    if targ.Type == 0 || targ.Type == obj.SXREF {
        ld.Diag("unknown symbol %s in pcrel", targ.Name)
    }
    r.Type = obj.R_PCREL
    r.Add += 4
    return

But this only applies to the symbols that the linker knows are being imported. I believe here the generated .o file has inside it a reference to __imp_longjmp, and the linker knows nothing about that, and in particular does not have it marked as SDYNIMPORT, so no error is produced.

I don't believe the linker is set up to handle this case. It's not just a trivial fix. Given that, we should probably leave this for Go 1.7.

[alexbrainman]

I did some debuging here:

diff --git a/src/cmd/link/internal/ld/ldpe.go b/src/cmd/link/internal/ld/ldpe.go
index 8439c06..d8788c9 100644
--- a/src/cmd/link/internal/ld/ldpe.go
+++ b/src/cmd/link/internal/ld/ldpe.go
@@ -128,6 +128,8 @@ type PeObj struct {
 }

 func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
+   fmt.Printf("\nprocessing file %s\n\n", pn)
+   defer fmt.Printf("\ndone with %s\n", pn)
    if Debug['v'] != 0 {
        fmt.Fprintf(&Bso, "%5.2f ldpe %s\n", obj.Cputime(), pn)
    }
@@ -199,6 +201,7 @@ func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
    // read symbols
    peobj.pesym = make([]PeSym, peobj.fh.NumberOfSymbols)

+   fmt.Printf("\npe symbols for %v:\n", pn)
    peobj.npesym = uint(peobj.fh.NumberOfSymbols)
    obj.Bseek(f, int64(base)+int64(peobj.fh.PointerToSymbolTable), 0)
    for i := 0; uint32(i) < peobj.fh.NumberOfSymbols; i += numaux + 1 {
@@ -223,6 +226,9 @@ func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
        if numaux < 0 {
            numaux = 0
        }
+       if strings.Contains(pn, "issue13672.a") {
+           fmt.Printf("%d: %v\t\tsection=%d value=0x%x\n", i, peobj.pesym[i].name, peobj.pesym[i].sectnum, peobj.pesym[i].value)
+       }
    }

    // create symbols for mapped sections
@@ -287,6 +293,7 @@ func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
            continue
        }

+       fmt.Printf("\npe relocations for section %v:\n", rsect.name)
        r = make([]Reloc, rsect.sh.NumberOfRelocations)
        obj.Bseek(f, int64(peobj.base)+int64(rsect.sh.PointerToRelocations), 0)
        for j = 0; j < int(rsect.sh.NumberOfRelocations); j++ {
@@ -297,6 +304,10 @@ func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
            rva := Le32(symbuf[0:])
            symindex := Le32(symbuf[4:])
            type_ := Le16(symbuf[8:])
+           if rsect.name == ".text" && strings.Contains(pn, "issue13672.a") {
+               fmt.Printf("%d: type=%v rva=0x%x symindex=%v\n", j, type_, rva, symindex)
+           }
+
            if err = readpesym(peobj, int(symindex), &sym); err != nil {
                goto bad
            }
@@ -348,6 +359,13 @@ func ldpe(f *obj.Biobuf, pkg string, length int64, pn string) {
        s = rsect.sym
        s.R = r
        s.R = s.R[:rsect.sh.NumberOfRelocations]
+
+       if rsect.name == ".text" && strings.Contains(pn, "issue13672.a") {
+           fmt.Printf("\ngo relocations for section %v:\n", s.Name)
+           for i, r := range s.R {
+               fmt.Printf("%d: Off=0x%x Sym(addr=%p name=%s type=%d dynimplib=%s extname=%s value=0x%x size=0x%x)\n", i, r.Off, r.Sym, r.Sym.Name, r.Sym.Type, r.Sym.Dynimplib, r.Sym.Extname, r.Sym.Value, r.Sym.Size)
+           }
+       }
    }

    // enter sub-symbols into symbol table.

and I get this output

C:\dev\src\issues\issue13672>go build -ldflags="-linkmode=internal"
# issues/issue13672

processing file $WORK\issues\issue13672.a(_all.o)


pe symbols for $WORK\issues\issue13672.a(_all.o):
0: .file        section=65534 value=0x12
2: .text        section=1 value=0x0
4: .data        section=3 value=0x0
6: .bss     section=8 value=0x0
8: .debug_info      section=10 value=0x0
10: .debug_abbrev       section=11 value=0x0
12: .debug_aranges      section=9 value=0x0
14: .debug_line     section=12 value=0x0
16: .rdata$zzz      section=5 value=0x20
18: .file       section=65534 value=0x31
20: Print       section=1 value=0x0
22: _cgo_7d1619ce4bb5_Cfunc_Print       section=1 value=0x50
23: .text       section=1 value=0x0
25: .data       section=3 value=0x0
27: .bss        section=8 value=0x0
29: .rdata      section=4 value=0x0
31: .xdata      section=7 value=0x0
33: .pdata      section=6 value=0x0
35: .debug_info     section=10 value=0x18f
37: .debug_abbrev       section=11 value=0x19
39: .debug_loc      section=15 value=0x0
41: .debug_aranges      section=9 value=0x20
43: .debug_line     section=12 value=0x1d
45: .rdata$zzz      section=5 value=0x0
47: .debug_frame        section=13 value=0x0
49: .file       section=65534 value=0x44
51: mingw_getsp     section=1 value=0x60
53: longjmp     section=1 value=0x66
54: .debug_info     section=10 value=0x4e5
56: .debug_abbrev       section=11 value=0x16c
58: .debug_line     section=12 value=0xc8
60: .text       section=1 value=0x60
62: .data       section=3 value=0x0
64: .bss        section=8 value=0x0
66: .debug_aranges      section=9 value=0x50
68: __imp_longjmp       section=0 value=0x0
69: puts        section=0 value=0x0
70: _setjmp     section=0 value=0x0

pe relocations for section .text:
0: type=4 rva=0x16 symindex=70
1: type=4 rva=0x21 symindex=29
2: type=4 rva=0x26 symindex=69
3: type=4 rva=0x41 symindex=53
4: type=4 rva=0x69 symindex=68

go relocations for section main(.text):
0: Off=0x16 Sym(addr=0xc0820697a0 name=_setjmp type=41 dynimplib=msvcrt.dll extname=_setjmp value=0x0 size=0x0)
1: Off=0x21 Sym(addr=0xc082f190e0 name=main(.rdata) type=8 dynimplib= extname=main(.rdata) value=0x0 size=0x20)
2: Off=0x26 Sym(addr=0xc0820705a0 name=puts type=41 dynimplib=msvcrt.dll extname=puts value=0x0 size=0x0)
3: Off=0x41 Sym(addr=0xc082070240 name=longjmp type=41 dynimplib=msvcrt.dll extname=longjmp value=0x0 size=0x0)
4: Off=0x69 Sym(addr=0xc082070240 name=longjmp type=41 dynimplib=msvcrt.dll extname=longjmp value=0x0 size=0x0)

pe relocations for section .pdata:

done with $WORK\issues\issue13672.a(_all.o)

processing file C:\dev\go/pkg/windows_amd64/runtime/cgo.a(_all.o)


pe symbols for C:\dev\go/pkg/windows_amd64/runtime/cgo.a(_all.o):

pe relocations for section .text:

pe relocations for section .pdata:

done with C:\dev\go/pkg/windows_amd64/runtime/cgo.a(_all.o)

Note that _all.o .text section has two interesting pe relocations: 3 and 4. 3 has symindex=53 which points to symbol

53: longjmp     section=1 value=0x66

that points to small longjmp function in .text. While 4 has symindex=68 which points to symbol

68: __imp_longjmp       section=0 value=0x0

which is just a place for external function (longjmp that gcc hoping to find in msvcrt.dll).

You can also see those relocations converted into "go relocations". But "go relocatoins" 3 and 4 points to the same symbol. And this symbol settings match neither original longjmp nor __imp_longjmp settings. So I am not surprised that linker generates invalid code here.

I think this is all to do with symbol renaming we do in readpesym.

Alex

[actgardner]

I'm experiencing the same issue with the external linker - I was able to reproduce the issue as redstorm described it: when Print() is defined in an external C file, the longjmp() call results in a stack trace.

It's a bit tough to follow here: are there any leads on why externally linked binaries would still have this issue?