Change https://golang.org/cl/345332 mentions this issue: runtime: ignore ctxt argument to crosscall2 calls to _cgo_panic

My test in https://golang.org/cl/345332 passes on 1.15 and bisection blames http://golang.org/cl/258938. That CL changed crosscall2 of _cgo_panic. Previously, crosscall2 directly called _cgo_panic, which explicitly called cgocallback with a nil ctxt. Afterwards, crosscall2 calls cgocallback directly, passing through the uninitialized ctxt.

cc @aclements

@gopherbot please open backport issues for 1.16 and 1.17.

This is a serious problem with no workaround besides modifying SWIG, which isn't really feasible.

Backport issue(s) opened: #47997 (for 1.16), #47998 (for 1.17).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@prattmic Checking in on this issue as we are reviewing backports. Any update on the status?

I've been on vacation, so the CL hasn't made much progress. Getting back to it now.

It doesn't help right away, but I'm planning to change SWIG so that instead of using crosscall2, it emits code like this in the generated Go file:

//go:linkname runtime_cgo_panic_internal runtime._cgo_panic_internal
func runtime_cgo_panic_internal(p *byte)

//export cgo_panic__voidtest_ac12e6cc23abb799
func cgo_panic__voidtest_ac12e6cc23abb799(p *byte) {
	runtime_cgo_panic_internal(p)
}

and this in the generated C/C++ file:

extern
#ifdef __cplusplus
  "C"
#endif
  void cgo_panic__voidtest_ac12e6cc23abb799(const char*);
static void _swig_gopanic(const char *p) {
  cgo_panic__voidtest_ac12e6cc23abb799(p);
}

The effect of this will be that future versions of SWIG will not use crosscall2, but they will depend on runtime._cgo_panic_internal.

Does that seem reasonable?

@ianlancetaylor , that seems reasonable to me. Is there a reason SWIG can't just call panic from the Go code? Is it just that we really want to be able to use gostringnocopy rather than, say, C.GoString, which does a heap allocation?

Yeah, I've thought about this more, and I think SWIG should just do it all itself.

My hesitation there is that it's hard to avoid adding this exported function to every SWIG generated file, and since it is exported it will be kept in the binary. The result for a program that uses SWIG for several different libraries is duplication of the panic code. But it may be possible to only emit the exported function if the code actually calls _swig_gopanic. It's not trivial because there are many different ways that SWIG can call that function.

OK, SWIG versions newer than 4.1.0 no longer call crosscall2.

I'm going to close this issue: the problem is really that SWIG was using an undocumented and unsupported API, and people who encounter the problem described here can now upgrade to a newer version of SWIG.