Can you write a standalone test case?

I can imagine several ways that longjmp will fail horribly in a Go program, but without knowing what Lua is doing here I don't know whether it can be expected to work or not.

Sadly, I haven't had any luck. The unit test I provided is now reproducing the problem consistently but even this code was running successfully with a slightly different verison of the lua.dll (some patches were appiled, but there were no modifications to the error handling routines)

@trink please try https://go-review.googlesource.com/#/c/5711/ see if it helps your problem. I don't have all mingw tools installed to try it myself.

Alex

Still seeing the same issue.

go version devel +ad3a99c Tue Feb 24 15:00:34 2015 +1100 windows/amd64

2/3 Test #24: sandbox ..........................***Failed    1.24 sec
2015/02/27 12:58:05 payload_type: txt
payload_name:
payload: Hello World!
2015/02/27 12:58:05 payload_type: txt
payload_name:
payload: Hello World!
2015/02/27 12:58:05 payload_type: txt
payload_name:
payload: Hello World!
Exception 0xc0000005 0x1 0x49eb2c 0x77a35bce
PC=0x77a35bce
signal arrived during cgo execution

github.com/mozilla-services/heka/sandbox/lua._Cfunc_process_message(0x3f6ce0, 0xc000000000)
        github.com/mozilla-services/heka/sandbox/lua/_obj/_cgo_gotypes.go:133 +0x43
github.com/mozilla-services/heka/sandbox/lua.(*LuaSandbox).ProcessMessage(0xc08200caf0, 0xc08200c870, 0x27)
        d:/work/heka/build/heka/src/github.com/mozilla-services/heka/sandbox/lua/lua_sandbox.go:618 +0x64
github.com/mozilla-services/heka/sandbox/lua_test.TestAPIErrors(0xc082056510)
        d:/work/heka/build/heka/src/github.com/mozilla-services/heka/sandbox/lua/lua_sandbox_test.go:330 +0x4e3
testing.tRunner(0xc082056510, 0x904218)
        d:/go/x64/src/testing/testing.go:448 +0xb4
created by testing.RunTests
        d:/go/x64/src/testing/testing.go:556 +0xa53

Fair enough. Thanks for trying.

Alex

Does it also crash on say Linux or OS X, or just Windows?
If it's just Windows we should be able to do whatever we do to defend against this on those systems.

Nope, not an issue on OSX or Linux, only Windows.

@rafrombrc have you tried current tip? @minux made big changes to windows cgo recently.

Alex

Last try was using code from here. I'll try tip and see i that makes a difference.

Please try current tip. Thank you.

Alex

If the external linking change fixes the problem then it's great.
However, if it's not, there are possibilities that the usage of
longjmp is just incompatible with cgo.

Without looking at the source code, I can't be sure whether the
longjmp usage is inherently incompatible with cgo.

On the plus side, as Lua's longjmp based error handling is portable,
if the problem doesn't exist on Linux, then I think the longjmp usage
should be fine and the external linking work should fix the windows
issue.

Please try again with the current tip. Thanks.
(the external linking code went in on Mar 23.)

Okay, I've tried the current tip (go version devel +399b3e3 Fri Apr 10 22:51:46 2015 +0000 windows/amd64). Unfortunately, I can't tell whether or not it resolved the original issue, because now I'm hitting a compiler error, it's panicking while trying to compile the executable. I've verified that it's only happening on Windows; on Linux everything compiles and the tests all pass.

did you pass some custom ldflags?

Yes, the general LDFLAGS value used was -s, and in certain of our Go files we're using a cgo LDFLAGS value of cgo LDFLAGS: ${LUA_LIB_PATH}/libluasandbox.dll ${LUA_LIB_PATH}/libluasb.dll -lm, where our build system replaces ${LUA_LIB_PATH} with the full filesystem path where the DLLs can be found before the Go compiler is invoked.

Okay, removed the LDFLAGS -s, was able to compile. It seems like things have improved, because the tests get farther than they did before, but they still crash. Sorry for using image pastes, I'm remotely logging into an AWS Windows box and can't figure out how to copy/paste text out of the MinGW command prompt. Anyway, here's the output:

Comparing that with what the original output @trink pasted above, you can see that the crash is happening later in the text execution. All of the go_lua_write_message_* output is expected, seeing that is an indication that things are still working, but eventually we still die.

this seems to have gone quiet ... any updates?

@johnjelinek From quick glance your CGO code crashes, uninitialised lua_sandbox handle is passed to process_message, which is the reason of said crash. Looking at the test code, especially ignored error here and here seems to confirm the theory. You may want to rewrite the test to not crash, and then eventually figure out the reason why it fails.

[edit] fixed links

It sounds like the longjmp is fixed, and now there is a problem in the test. Is that right?

As Russ says, it sounds like this problem is fixed. I'm going to close it. But please do reopen the issue if you can recreate it.

Confirmed, the test no longer cores in Go 1.5 Beta 2