Raspberry Pi 2 build (allegedly) successful, but fails to run

[nonnymoose]

@jimson-jimson had the same issue as I did: SIGILL, illegal instruction, but he didn't elaborate. I got 0 (zero) errors, from downloading it to testing it to building it, and still it did not run. Does this mean that it is an issue with the code? Attached is the shell script I used to build it (found here) and the log I created, which contains a backtrace of the failed run.

limecmd.txt
instlime.sh.txt

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35052234-raspberry-pi-2-build-allegedly-successful-but-fails-to-run?utm_campaign=plugin&utm_content=tracker%2F9076898&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F9076898&utm_medium=issues&utm_source=github).

[zoli]

do you get the same result with export GODEBUG=cgocheck=0?

[ricochet1k]

I can't tell for sure without a GDB stack trace, but it looks likely that the bad instruction is actually in the Python library, not gopy or in Go code. Maybe Python was built wrong?

[nonnymoose]

@zoli Very good point! I didn't at first, but as you can see in my script (which is totally not copied and pasted from here), I did eventually remember that and got the same result.
@ricochet1k That seems pretty unlikely to me. I have installed the Ubuntu python package from here and have installed and run mps-youtube as a python package without any issues. I'll try to get a GDB stack trace for you.

[nonnymoose]

@ricochet1k The gdb stacktrace was almost useless and recieved a different signal, SIGSEGV:

(gdb) run
Starting program: /home/me/golang/src/github.com/limetext/lime-qml/main/main 

Program received signal SIGSEGV, Segmentation fault.
0x76fd9822 in ?? () from /lib/ld-linux-armhf.so.3
(gdb) bt
#0  0x76fd9822 in ?? () from /lib/ld-linux-armhf.so.3
#1  0x76fd983a in ?? () from /lib/ld-linux-armhf.so.3
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) continue
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt
No stack.

Here is what I get when I run it normally:

$ ./main
SIGILL: illegal instruction
PC=0x75abbad2 m=0
signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x310570, 0x538b9e1c, 0x0)
    /usr/lib/go-1.6/src/runtime/cgocall.go:123 +0x11c fp=0x538b9df8 sp=0x538b9de0
github.com/limetext/gopy/lib._Cfunc_Py_InitializeEx(0x0)
    ??:0 +0x34 fp=0x538b9e18 sp=0x538b9df8
github.com/limetext/gopy/lib.initAndLock(0x0, 0x53866973)
    /home/me/golang/src/github.com/limetext/gopy/lib/lock.go:60 +0xd8 fp=0x538b9e3c sp=0x538b9e18
github.com/limetext/gopy/lib.InitAndLock(0x61728)
    /home/me/golang/src/github.com/limetext/gopy/lib/lock.go:42 +0x20 fp=0x538b9e48 sp=0x538b9e3c
github.com/limetext/sublime/api.init.1()
    /home/me/golang/src/github.com/limetext/sublime/api/sublime_api.go:77 +0x1c fp=0x538b9f48 sp=0x538b9e48
github.com/limetext/sublime/api.init()
    /home/me/golang/src/github.com/limetext/sublime/api/window_manual.go:112 +0x998 fp=0x538b9f78 sp=0x538b9f48
github.com/limetext/sublime.init()
    /home/me/golang/src/github.com/limetext/sublime/syntax.go:48 +0x68 fp=0x538b9f7c sp=0x538b9f78
main.init()
    /home/me/golang/src/github.com/limetext/lime-qml/main/window.go:51 +0x90 fp=0x538b9f9c sp=0x538b9f7c
runtime.main()
    /usr/lib/go-1.6/src/runtime/proc.go:177 +0x274 fp=0x538b9fc4 sp=0x538b9f9c
runtime.goexit()
    /usr/lib/go-1.6/src/runtime/asm_arm.s:990 +0x4 fp=0x538b9fc4 sp=0x538b9fc4

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/lib/go-1.6/src/runtime/asm_arm.s:990 +0x4

goroutine 35 [chan receive]:
github.com/limetext/log4go.ConsoleLogWriter.run(0x539260c0, 0x41eb21c0, 0x538de0f8)
    /home/me/golang/src/github.com/limetext/log4go/termlog.go:27 +0x6c
created by github.com/limetext/log4go.NewConsoleLogWriter
    /home/me/golang/src/github.com/limetext/log4go/termlog.go:19 +0x74

goroutine 36 [chan receive]:
github.com/limetext/log4go.ConsoleLogWriter.run(0x53926100, 0x41eb21c0, 0x538de0f8)
    /home/me/golang/src/github.com/limetext/log4go/termlog.go:27 +0x6c
created by github.com/limetext/log4go.NewConsoleLogWriter
    /home/me/golang/src/github.com/limetext/log4go/termlog.go:19 +0x74

goroutine 37 [syscall]:
syscall.Syscall6(0xfc, 0x4, 0x53967dac, 0x7, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go-1.6/src/syscall/asm_linux_arm.s:48 +0x8
golang.org/x/sys/unix.EpollWait(0x4, 0x53967dac, 0x7, 0x7, 0xffffffff, 0x0, 0x0, 0x0)
    /home/me/golang/src/golang.org/x/sys/unix/zsyscall_linux_arm.go:1632 +0x90
gopkg.in/fsnotify%2ev1.(*fdPoller).wait(0x538f05b0, 0x438700, 0x0, 0x0)
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify_poller.go:86 +0x84
gopkg.in/fsnotify%2ev1.(*Watcher).readEvents(0x538f4270)
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify.go:192 +0x1e8
created by gopkg.in/fsnotify%2ev1.NewWatcher
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify.go:61 +0x3a4

goroutine 38 [select]:
github.com/limetext/backend/watch.(*Watcher).Observe(0x538f42a0)
    /home/me/golang/src/github.com/limetext/backend/watch/watcher.go:209 +0x240
created by github.com/limetext/backend/packages.init.1
    /home/me/golang/src/github.com/limetext/backend/packages/watcher.go:56 +0x148

goroutine 39 [chan receive]:
github.com/limetext/text.(*SerializedBuffer).worker(0x539000f4)
    /home/me/golang/src/github.com/limetext/text/serialized_buffer.go:40 +0x48
created by github.com/limetext/text.(*SerializedBuffer).init
    /home/me/golang/src/github.com/limetext/text/serialized_buffer.go:26 +0xd0

goroutine 40 [syscall]:
syscall.Syscall6(0xfc, 0x8, 0x53997dac, 0x7, 0xffffffff, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/lib/go-1.6/src/syscall/asm_linux_arm.s:48 +0x8
golang.org/x/sys/unix.EpollWait(0x8, 0x53997dac, 0x7, 0x7, 0xffffffff, 0x0, 0x0, 0x0)
    /home/me/golang/src/golang.org/x/sys/unix/zsyscall_linux_arm.go:1632 +0x90
gopkg.in/fsnotify%2ev1.(*fdPoller).wait(0x538f05c0, 0x438700, 0x0, 0x0)
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify_poller.go:86 +0x84
gopkg.in/fsnotify%2ev1.(*Watcher).readEvents(0x538f42d0)
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify.go:192 +0x1e8
created by gopkg.in/fsnotify%2ev1.NewWatcher
    /home/me/golang/src/gopkg.in/fsnotify.v1/inotify.go:61 +0x3a4

goroutine 41 [chan receive]:
github.com/limetext/backend/log.NewLogWriter.func1(0x538f0600, 0x538de350)
    /home/me/golang/src/github.com/limetext/backend/log/logwriter.go:38 +0x44
created by github.com/limetext/backend/log.NewLogWriter
    /home/me/golang/src/github.com/limetext/backend/log/logwriter.go:41 +0xa0

goroutine 42 [chan receive]:
github.com/limetext/backend.(*Editor).inputthread(0x53934240)
    /home/me/golang/src/github.com/limetext/backend/editor.go:376 +0xa4
created by github.com/limetext/backend.GetEditor
    /home/me/golang/src/github.com/limetext/backend/editor.go:159 +0x1398

goroutine 43 [select]:
github.com/limetext/backend/watch.(*Watcher).Observe(0x538f4300)
    /home/me/golang/src/github.com/limetext/backend/watch/watcher.go:209 +0x240
created by github.com/limetext/backend.GetEditor
    /home/me/golang/src/github.com/limetext/backend/editor.go:160 +0x13bc

trap    0x6
error   0x0
oldmask 0x0
r0      0x75f3f970
r1      0x80
r2      0x40000000
r3      0x75b7f79c
r4      0x75f3f378
r5      0x75ebb000
r6      0x0
r7      0x75b7fdf8
r8      0x1
r9      0x0
r10     0x41ea2570
fp      0x8
ip      0x75abbad1
sp      0x7ee5d068
lr      0x75c93563
pc      0x75abbad2
cpsr    0xe0030
fault   0x0

[ricochet1k]

Weird. I have a Raspberry Pi 2, so I might try to make it run on there sometime. It sounds to me like gdb is not working correctly, or maybe the linker. I think /lib/ld-linux-armhf.so.3 is part of the linker library. Golang might be producing some weird binaries.

[nonnymoose]

@ricochet1k
Wow. Now that you point that out, I was doing a coding challenge yesterday and had the exact same problem, including the memory addresses!
You are probably right about the linker. Is it something I can fix?

[quarnster]

@nonnymoose GDB is from my experience crap with go. Try lldb instead and get the backtrace as well as the disassembly around $PC at the SIGILL.