You already emailed golang-nuts for help and that thread is active, so let's keep it there instead of the bug tracker until a bug has been identified.

Also, please gofmt your code in the future.

@bradfitz on the thread I asked the OP to open a bug report with a reproduction case.

Does Anyone have the same result?

my c.dll program is:

How do I build c.dll?
Thank you.

Alex

@alexbrainman
I put the solution file on this site:https://groups.google.com/forum/#!topic/golang-nuts/2YpUrnjiY6k

I put the solution file on this site:https://groups.google.com/forum/#!topic/golang-nuts/2YpUrnjiY6k

I do not know how to use your "solution".
I was trying to follow steps you provided above, but the c.dll is missing. How do I build c.dll?

Alex

Anyone can give a explanation?

I think this thread is the my answer:https://github.com/golang/go/issues/14599

Issue #14599 is fixed in 1.7.1, so whatever you are encountering is unlikely to be the same problem.

@ianlancetaylor
Do you repro the program?Or have more information ?

I don't use Windows, so I have not tried to reproduce this problem.

alexbrainman tried to reproduce it, ran into a problem, and asked you a question that you have not answered. See above: he asked "How do I build c.dll?"

@supernow Why you take an address of callback pointer? I don't reproduce with following code.

test0001.c

#include <process.h>
#include <stdio.h>

typedef void (*callback) (int, int, char*);

callback goCallback;

void
timeProc(void *p) {
  for (;;) {
    goCallback(1, 2, "Hello");
  }
}

void
init(void* p) {
  goCallback = p;
  printf("init success!\n");
  _beginthread(&timeProc, 0, 0);
  printf("End \n");
}

test.go

package main

import (
    "C"
    "fmt"
    "net/http"
    _ "net/http/pprof"
    "os"
    "runtime/pprof"
    "syscall"
    "time"
)

var (
    times = 0
    dll   = syscall.NewLazyDLL("test0001.dll")
    proc  = dll.NewProc("init")
)

func main() {
    proc.Call(syscall.NewCallback(goCbStr))
    f, _ := os.Create("cpu.prof")
    err := pprof.StartCPUProfile(f)
    if err != nil {
        fmt.Println("pprof.StartCPUProfile:", err)
    }
    defer pprof.StopCPUProfile()
    go func() {
        fmt.Println(http.ListenAndServe("localhost:54321", nil))
    }()
    for {
        time.Sleep(time.Second)
    }
}

func goCbStr(callId int, funtype int, str *C.char) uintptr {
    times++
    fmt.Println(times, callId, funtype, C.GoString(str))
    return uintptr(0)
}

@mattn
Why you take an address of callback pointer?
I only know this way to callback go. Is there another way to callback go. Can you give me a site?

@alexbrainman
I share my C.dll solution file on this site:

@mattn
What's you environment?
In my program, goCbStr can be called over 2000 times,then either print "malloc deadlock" or stuck over there.

I use you golang program to call my dll, It just output:

 "init success! End".

There is no func goCbStr calleback. I change your golang program line

proc.Call(syscall.NewCallback(goCbStr))

to

callBack_ := syscall.NewCallback(goCbStr)
proc.Call(uintptr(unsafe.Pointer(&callBack_)))

It have the same the error with mine!

Thank you for repro my error!

What's you environment?

Windows7 64bit.

@ianlancetaylor I'm not sure, the address given from &callBack_ is temporary? AFAIK, it's safe to access the address even though it's in C while alive in main func. Right?

@mattn
I figure out that you dll code is ：

init(void* p) {
  goCallback = p;

my dll code is

void init(cbStr* p) {
    goCallback = *p;

When I rewrite it like you:
I got the same error.

BTW, What's your golang edition? Is it 1.7.1 edition?

It's not safe to take the address of a value, convert the address to uintptr, and pass that address to a function other than syscall.Syscall. See https://golang.org/pkg/unsafe/#Pointer .

In this case I don't understand why the code is written that way.

So I guess this is not a bug.

I share my C.dll solution file on this site:

Thank you for the link. Unfortunately this needs some MS build tool to create the DLL, and I do not have that. So I will try to comment your code without actually running it. So I could be wrong about many things.

Your golang test.cpp:15 (init function) starts new thread, and new thread (timeProc function) calls Go callback. That will not work. The syscall.NewCallback can only be called by the no-Go code that is called by syscall.Syscall (or syscall.(*Proc).Call) before it return back to Go.

Also your DLL functions must use standard calling conventions: stdcall on 386 and "whatever Windows uses" on amd64. Your C build tool must generate appropriate code for both init and goCallback.

Also syscall.Syscall and syscall.NewCallback both align its parameters and return value on 4 bytes for 386 and 8 bytes for amd64. Does your C build tool does the same? You need to make sure it does.

I hope it helps.

Alex

Thank you for replies.

The syscall.NewCallback can only be called by the no-Go code that is called by syscall.Syscall (or syscall.(*Proc).Call) before it return back to Go.

As far as I understand, in this scenario I can not callback golang func. However , If I want to create a new thread that can callback Go Code, what need I do?

BTW, In my program, when I remove code

 f, _ := os.Create("cpu.prof")
    err := pprof.StartCPUProfile(f)
    if err != nil {
        fmt.Println("pprof.StartCPUProfile:", err)
    }
    defer pprof.StopCPUProfile()

The program run well.

I think the CPU profile have the effect on the callback

To call Go code from a new non-Go thread, use cgo (https://golang.org/cmd/cgo).

However , If I want to create a new thread that can callback Go Code, what need I do?

I do not know. Maybe try what Ian suggested, but I have not done that myself.

I think the CPU profile have the effect on the callback

I am not sure why. Maybe you are just lucky.

Alex

@alexbrainman, why do you say that a syscall.NewCallback-created callback can't be invoked on a new Windows-created thread? I think that should work, and it clearly mostly works. @ianlancetaylor, syscall.NewCallback returns a Windows callback that can be used to invoke the Go code. Underneath it translates to the usual cgo entry points. In particular, when the callback is invoked, it ends up in cgocallback_gofunc (on the stack above), which will take care of borrowing an M appropriately.

But the borrowing of M's and the profiling of M's by the CPU profiler seem not synchronized enough. This code implements the CPU profiler on Windows:

func profileloop1(param uintptr) uint32 {
    stdcall2(_SetThreadPriority, currentThread, _THREAD_PRIORITY_HIGHEST)

    for {
        stdcall2(_WaitForSingleObject, profiletimer, _INFINITE)
        first := (*m)(atomic.Loadp(unsafe.Pointer(&allm)))
        for mp := first; mp != nil; mp = mp.alllink {
            thread := atomic.Loaduintptr(&mp.thread)
            // Do not profile threads blocked on Notes,
            // this includes idle worker threads,
            // idle timer thread, idle heap scavenger, etc.
            if thread == 0 || mp.profilehz == 0 || mp.blocked {
                continue
            }
            stdcall1(_SuspendThread, thread)
            if mp.profilehz != 0 && !mp.blocked {
                profilem(mp)
            }
            stdcall1(_ResumeThread, thread)
        }
    }
}

func profilem(mp *m) {
    var r *context
    rbuf := make([]byte, unsafe.Sizeof(*r)+15)

    tls := &mp.tls[0]
    gp := *((**g)(unsafe.Pointer(tls)))

    // align Context to 16 bytes
    r = (*context)(unsafe.Pointer((uintptr(unsafe.Pointer(&rbuf[15]))) &^ 15))
    r.contextflags = _CONTEXT_CONTROL
    stdcall2(_GetThreadContext, mp.thread, uintptr(unsafe.Pointer(r)))
    sigprof(r.ip(), r.sp(), 0, gp, mp)
}

func sigprof(pc, sp, lr uintptr, gp *g, mp *m) {
    if prof.hz == 0 {
        return
    }

    // Profiling runs concurrently with GC, so it must not allocate.
    mp.mallocing++

    ... lots of code ...

    mp.mallocing--
}

A borrowed M may migrate between threads. Between the atomic.Loaduintptr(&mp.thread) and the SuspendThread, mp may have moved to a new thread, so that it's in active use. In particular it might be calling malloc, as in the crash stack trace. If so, the mp.mallocing++ in sigprof would provoke the crash.

Those lines are trying to guard against allocation during sigprof. But on Windows, mp is the thread being traced, not the current thread. Those lines should really be using getg().m.mallocing, which is the same on Unix but not on Windows. With that change, it's possible the race on the actual thread is not a problem: the traceback would get confused and eventually return an error, but that's fine. The code expects that possibility.

It would be nice if we could reproduce the problem, though. It might suffice just to turn on CPU profiling and make a bunch of callbacks from multiple threads simultaneously.

@alexbrainman, why do you say that a syscall.NewCallback-created callback can't be invoked on a new Windows-created thread? I think that should work, and it clearly mostly works.

See issue #6751. I did not look at this for a while, so it could be well fixed now.

Anyway we use syscall.NewCallback mainly for GUI. And there all callbacks happen on the same thread.

Alex

CL https://golang.org/cl/33132 mentions this issue.