what means "fatal error: malloc/free - deadlock"?

[Lubos Pintes]

What the error means, exactly?
Or what it means when it happens in a Syscall?

[Dave Cheney]

It is an error in the runtime, it is certainly not expected.

Can you please provide the entire panic message, you go version (go
version, or hg id), and your platform.

On Wed, Sep 18, 2013 at 6:28 PM, Lubos Pintes <lubos....@gmail.com> wrote:
> What the error means, exactly?
> Or what it means when it happens in a Syscall?
>

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Lubos Pintes]

Go version:
go version devel +45343b9c3db4 Mon Sep 16 22:53:12 2013 +1000 windows/386

Panic message:
fatal error: malloc/free - deadlock
[signal 0xc0000005 code=0x0 addr=0x10 pc=0x424bda]

runtime stack:
runtime: unexpected return pc for runtime.sigpanic called from 0x77238e19
runtime.throw(0x63ece0)
C:/vcs/go/src/pkg/runtime/panic.c:464 +0x67
runtime.mallocgc(0x8, 0x0, 0x0)
C:/vcs/go/src/pkg/runtime/malloc.goc:51 +0x4f
runtime.mal(0x8)
C:/vcs/go/src/pkg/runtime/malloc.goc:700 +0x3a
copyin(0x4f5ae0, 0x32cafb98, 0x32cafba4)
C:/vcs/go/src/pkg/runtime/iface.c:153 +0x5c
runtime.convT2E(0x4f5ae0, 0x63dccf, 0x31, 0x4f5ae0, 0x31)
C:/vcs/go/src/pkg/runtime/iface.c:221 +0x32
runtime.newErrorString(0x63dccf, 0x31, 0x32cafbc0)
C:/vcs/go/src/pkg/runtime/error.go:74 +0x3a
runtime.panicstring(0x63dccf)
C:/vcs/go/src/pkg/runtime/panic.c:477 +0x82
runtime.sigpanic()
C:/vcs/go/src/pkg/runtime/os_windows.c:337 +0xb4
runtime.mallocgc(0x8, 0x0, 0x0)
C:/vcs/go/src/pkg/runtime/malloc.goc:70 +0xca
runtime.mal(0x8)
C:/vcs/go/src/pkg/runtime/malloc.goc:700 +0x3a
copyin(0x4f5ae0, 0x32cafc60, 0x32cafc6c)
C:/vcs/go/src/pkg/runtime/iface.c:153 +0x5c
runtime.convT2E(0x4f5ae0, 0x63dccf, 0x31, 0x4f5ae0, 0x31)
C:/vcs/go/src/pkg/runtime/iface.c:221 +0x32
runtime.newErrorString(0x63dccf, 0x31, 0x32cafc88)
C:/vcs/go/src/pkg/runtime/error.go:74 +0x3a
runtime.panicstring(0x63dccf)
C:/vcs/go/src/pkg/runtime/panic.c:477 +0x82
runtime: unexpected return pc for runtime.sigpanic called from 0x77238e19
runtime.sigpanic()
C:/vcs/go/src/pkg/runtime/os_windows.c:337 +0xb4

goroutine 5 [syscall]:
runtime.cgocall(0x42b6d0, 0x12139b88)
C:/vcs/go/src/pkg/runtime/cgocall.c:149 +0x10c fp=0x12139b80
syscall.Syscall(0x7641787b, 0x1, 0x1212fdc0, 0x0, 0x0, ...)
C:/vcs/go/src/pkg/runtime/syscall_windows.goc:55 +0x4b fp=0x12139ba4
github.com/lxn/win.DispatchMessage(0x1212fdc0, 0x0)
c:/go/src/github.com/lxn/win/user32.go:1843 +0x4c fp=0x12139bc8
main.func·001()
C:/speechd/sapi4.go:181 +0x37d fp=0x1213bd0c
----- stack segment boundary -----
runtime.goexit()
C:/vcs/go/src/pkg/runtime/proc.c:1386 fp=0x32c317d0
created by main.NewSAPI4
C:/speechd/sapi4.go:184 +0xef

goroutine 1 [chan receive]:
main.main()
C:/speechd/main.go:97 +0x15e

goroutine 3 [syscall]:
runtime/pprof.profileWriter(0x17c168, 0x12100250)
C:/vcs/go/src/pkg/runtime/pprof/pprof.go:600 +0x23
created by runtime/pprof.StartCPUProfile
C:/vcs/go/src/pkg/runtime/pprof/pprof.go:594 +0x132

goroutine 4 [syscall]:
syscall.Syscall(0x7641787b, 0x1, 0x1212d920, 0x0, 0x0, ...)
C:/vcs/go/src/pkg/runtime/syscall_windows.goc:55 +0x4b
github.com/lxn/win.DispatchMessage(0x1212d920, 0x0)
c:/go/src/github.com/lxn/win/user32.go:1843 +0x4c
main.processMessages()
C:/speechd/utils.go:13 +0x85
main.handler(0x17d1d8, 0x12100368)
C:/speechd/main.go:68 +0x61a
created by main.main
C:/speechd/main.go:96 +0x146

[Dmitry Vyukov]

This may be caused by a data race, try running the program with -race flag.
Or by heap corruption in cgo code.

[Lubos Pintes]

The -race flag doesn't work for me:
"go run: -race is only supported on linux/amd64, darwin/amd64 and
windows/amd64"
Maybe this is a stupid question. I have an 64-bit processor manufactured
by AMD (Llano AND A6-3410MX) so, is my case "Windows/AMD64" or not?

[Nico]

the output of your "go version" says is windows/386

[Brady.S...@iwsinc.com]

Looks like he might need 64 bit Go for windows? http://code.google.com/p/go/downloads/detail?name=go1.1.2.windows-amd64.msi&can=2&q=

On Wednesday, September 18, 2013 10:39:54 AM UTC-7, Nico wrote:

the output of your "go version" says is windows/386

The information contained in this transmission contains potentially privileged, export controlled and/or confidential information of Imageware Systems, Inc. or its customers or partners.  It is intended only to be read by the person(s) named above and for no other purpose.  You are hereby notified that any dissemination, distribution, duplication of this communication or use of its contents for any purpose not authorized expressly by Imageware Systems, Inc. is strictly prohibited and could lead to both civil and/or criminal penalties.  If you are not the intended recipient, you are prohibited to review the contents herein and please contact the sender by reply e-mail and destroy all copies of the original message.  To reply to our e-mail administrator directly, please send an e-mail to email...@iwsinc.com

[Lubos Pintes]

Yes. This was the default compilation. I already had MinGW installed,
and just ran make after cloning Go repo.

[minux]

On Sep 18, 2013 1:55 PM, "Lubos Pintes" <lubos....@gmail.com> wrote:
>
> Yes. This was the default compilation. I already had MinGW installed, and just ran make after cloning Go repo.

please make sure you're using 64-bit version of windows,
and you're using 64-bit mingw gcc.

otherwise, it won't get a 64-bit go built.

[James Bardin]

I've had this same error on osx by inadvertently overriding go's signal handlers in cgo. If you're calling anything from C you have to make sure no libraries register their own signal handlers.

[Lubos Pintes]

I am not sure what a signal handler is in Windows context.
But I can remember, that the COM library I am using could throw a COM
exception. I am doing error checking everywhere, and if I understand COM
properly, an exception is really only a return code.

D�a 18. 9. 2013 20:01 minux wrote / nap�sal(a):
>
> On Sep 18, 2013 1:55 PM, "Lubos Pintes"
> <lubos....@gmail.com

> <mailto:lubos....@gmail.com>> wrote:
> >
> > Yes. This was the default compilation. I already had MinGW installed,
> and just ran make after cloning Go repo.
> please make sure you're using 64-bit version of windows,
> and you're using 64-bit mingw gcc.
>
> otherwise, it won't get a 64-bit go built.
>

[brainman]

On Wednesday, 18 September 2013 19:48:08 UTC+10, Lubos Pintes wrote:

> Go version: 

> go version devel +45343b9c3db4 Mon Sep 16 22:53:12 2013 +1000 windows/386 

> 

> Panic message: 

> fatal error: malloc/free - deadlock 

> [signal 0xc0000005 code=0x0 addr=0x10 pc=0x424bda] 

> ...

> runtime.sigpanic() 

>         C:/vcs/go/src/pkg/runtime/os_windows.c:337 +0xb4 

Your program received an exception, and it is trying to print the exception information. And it is confused about it. Perhaps there is something for Go to fix here:

https://code.google.com/p/go/issues/detail?id=6419

As to your original problem, you hit "case EXCEPTION_ACCESS_VIOLATION" in runtime.sigpanic (in os_windows.c). That means you are trying to access memory you don't have permission to access to.

When you call into Windows API, it is very important for you to not make mistakes. If your parameter has wrong size - Windows will not notice that - it will read from / write to wrong memory address. If you pass pointer to a memory block to Windows, and Windows API says you must keep that memory block alive until some later time - then you must prevent Go garbage collection from freeing that block earlier. There are million ways to shoot yourself in the foot. And these are fatal, because once internal memory is corrupted, anything can happens. Once you leave safe world of Go, you are on your own.

I don't know of a *general* solution to this problem. Understand Windows APIs you call. Keep it simple. Write tests.

Alex

[brainman]

On Thursday, 19 September 2013 02:53:38 UTC+10, Dmitry Vyukov wrote:

This may be caused by a data race, try running the program with -race flag.
Or by heap corruption in cgo code.

Just a crazy idea. Would it be possible to modify Go memory manager to try and catch these "corruption" errors? Maybe allocate little more memory then requested and write something at the end to be verified on free. This mode will be optionally switched on as race detector to verify programs for memory corruption.

Alex 

[brainman]

On Thursday, 19 September 2013 10:02:03 UTC+10, brainman wrote:

I have forgotten to say. Since Go stack trace is not very useful, you might get better luck with gdb. gdb will stop on your original exception, then you might be able to determine where it happens and decide why it happens.

Alex