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

runtime/cgo: GO->CGO->JNI->CGO->GO runtime.mallocgc failed in Mac amd64 #53969

Closed
GrapeBaBa opened this issue Jul 20, 2022 · 4 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-Darwin
Milestone

Comments

@GrapeBaBa
Copy link

GrapeBaBa commented Jul 20, 2022

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

$ go version
go version go1.17 darwin/amd64

Does this issue reproduce with the latest release?

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

go env Output
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/kaichen/Library/Caches/go-build"
GOENV="/Users/kaichen/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/kaichen/Documents/go/pkg/mod"
GONOPROXY=""
GONOSUMDB="*"
GOOS="darwin"
GOPATH="/Users/kaichen/Documents/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/qc/861jkvsd2y192wpj6nflrzbr0000gn/T/go-build2904134262=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

1.We have a go program to start JVM through cgo, and invoke java object method.
2.The java program has some native method which implemented also by cgo code. Through system.load load the dynamic lib which build by go build -buildmode=c-shard.

The main go program

package main

import (
	"log"
	"os"
	"unsafe"

	"util"
	"types"
)

/*
#include <jni.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>
#include <string.h>

char* joinStr(char *s1, char *s2) {
  char *result = malloc(strlen(s1)+strlen(s2)+1);
  strcpy(result, s1);
  strcat(result, s2);
  return result;
}

jint createJVM(JavaVM **jvm, JNIEnv **env, char* JVMPath) {

}

*/
import "C"

func init() {
	contextManager = types.NewContextManager()
}

func initJVM() util.Env {

}

func main() {
	initJVM()
}

The java program

package jvm.core.syscall;

import java.io.IOException;

public class SyscallStub {

    static {
        init();
    }

    private native static void init();

    public native static void putState(long contextManagerPtr, byte[] txHash, String contractName, byte[] key, byte[] value) throws SyscallException;
//
//    public native byte[] getState(byte[] txHash, String contractName, byte[] key) throws SyscallException;
}

The dynamic lib go program

package main

// #include "jni.h"
import "C"
import (
	"encoding/hex"
	"unsafe"

	"util"
	"types"
)

//export Java_jvm_core_syscall_SyscallStub_init
func Java_jvm_core_syscall_SyscallStub_init(jenv *C.JNIEnv, jSyscallClass C.jclass) {

	env := util.Env(unsafe.Pointer(jenv))

	_ = util.Init(env)


}


func main() {

}

What did you expect to see?

I want to see correct results.

What did you see instead?

GOROOT=/usr/local/go #gosetup
GOPATH=/Users/kaichen/Documents/go #gosetup
/usr/local/go/bin/go build -o 
0
fatal error: bad sweepgen in refill

goroutine 1 [running, locked to thread]:
runtime.throw({0x4c98b62, 0xc0000001a0})
        /usr/local/go/src/runtime/panic.go:1198 +0x71 fp=0xc0018bfd88 sp=0xc0018bfd58 pc=0x4036011
runtime.(*mcache).refill(0xf940a68, 0x5)
        /usr/local/go/src/runtime/mcache.go:156 +0x24e fp=0xc0018bfdd8 sp=0xc0018bfd88 pc=0x40184ce
runtime.(*mcache).nextFree(0xf940a68, 0x5)
        /usr/local/go/src/runtime/malloc.go:880 +0x85 fp=0xc0018bfe20 sp=0xc0018bfdd8 pc=0x400e1e5
runtime.mallocgc(0x8, 0x4b062c0, 0x1)
        /usr/local/go/src/runtime/malloc.go:1046 +0x331 fp=0xc0018bfea0 sp=0xc0018bfe20 pc=0x400e6b1
runtime.newobject(0x0)
        /Users/kaichen/Documents/projects/jvm-glue-go-test/util/util.go:80 +0x32 fp=0xc0018bff60 sp=0xc0018bfec8 pc=0x40f2bf2
main.main()
        /Users/kaichen/Documents/projects/jvm-glue-go-test/syscall_skeleton_foo1.go:11 +0x1e fp=0xc0018bff80 sp=0xc0018bff60 pc=0x4a463de
runtime.main()
        /usr/local/go/src/runtime/proc.go:255 +0x227 fp=0xc0018bffe0 sp=0xc0018bff80 pc=0x40386a7
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1581 +0x1 fp=0xc0018bffe8 sp=0xc0018bffe0 pc=0x4065ec1
@GrapeBaBa GrapeBaBa changed the title affected/package: GO->CGO->JNI->CGO->GO runtime.mallocgc failed in Mac amd64 Jul 20, 2022
@GrapeBaBa
Copy link
Author

uname -a 
Darwin Kais-MacBook-Pro.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64

@GrapeBaBa
Copy link
Author

We tested the same code in linux and Mac arm, it works.

@toothrot toothrot changed the title GO->CGO->JNI->CGO->GO runtime.mallocgc failed in Mac amd64 runtime/cgo: GO->CGO->JNI->CGO->GO runtime.mallocgc failed in Mac amd64 Jul 20, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 20, 2022
@toothrot toothrot added OS-Darwin and removed compiler/runtime Issues related to the Go compiler and/or runtime. labels Jul 20, 2022
@toothrot toothrot added this to the Backlog milestone Jul 20, 2022
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 20, 2022
@toothrot
Copy link
Contributor

Is this related to #38692?

@cherrymui
Copy link
Member

Yeah, it looks like related to #38692. Basically, it doesn't work that in the same process there is a Go c-shared library and other Go code (the main executable). The c-shared build mode is not designed to support multiple copies of the Go runtime, so when there are, something will go wrong.

Each platform has different symbol deduplication mechanism at dynamic linking time. It might be possible that on some platform it "happens to work", to some extent. But still, as various runtime data are not combined, things will go wrong.

Closing as a dup of #38692. Thanks.

@cherrymui cherrymui closed this as not planned Won't fix, can't repro, duplicate, stale Jul 20, 2022
@golang golang locked and limited conversation to collaborators Jul 21, 2023
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-Darwin
Projects
None yet
Development

No branches or pull requests

4 participants