issues with new runtime/cgo changes

[Albert Strasheim]

go version devel +bfb45be43e2b Thu Feb 21 13:11:58 2013 +1100 linux/amd64

GOMAXPROCS=123

./run.bash --no-rebuild

# ../misc/cgo/test

free 0xc20015a000: not an allocated block
fatal error: free runtime·mlookup

goroutine 0 [running]:
[fp=0x7f4c4af38e00] runtime.throw(0x5ee26b, 0xc20015a000)
	/build/go.tip/go/src/pkg/runtime/panic.c:464 +0x67
[fp=0x7f4c4af38e50] runtime.free(0xc20015a000, 0xc200159038)
	/build/go.tip/go/src/pkg/runtime/zmalloc_linux_amd64.c:134 +0xa8
[fp=0x7f4c4af38e90] runtime.panic(0x50cb70, 0xc200147c00)
	/build/go.tip/go/src/pkg/runtime/panic.c:233 +0x161
[fp=0x7f4c4af38ed0] runtime.panicstring(0x5ed433, 0x0)
	/build/go.tip/go/src/pkg/runtime/panic.c:478 +0xa3
[fp=0x7f4c4af38ee8] runtime.sigpanic()
	/build/go.tip/go/src/pkg/runtime/thread_linux.c:207 +0x168
[fp=0x7f4c4af38ef8] _/build/go.tip/go/misc/cgo/test.Add(0x0, 0x7f4c4af38100)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:634 +0x5c
----- stack segment boundary -----
[fp=0x7f4c4af38f98] runtime.cgocallbackg(0x42f580, 0x7f4c317f9eb0, 0x8, 0x413a80, 0x0, ...)
	/build/go.tip/go/src/pkg/runtime/cgocall.c:237 +0x118
[fp=0x7f4c4af38fb8] runtime.cgocallback(0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/build/go.tip/go/src/pkg/runtime/asm_amd64.s:578 +0x71
[fp=0x7f4c4af38fc0] runtime.goexit()
	/build/go.tip/go/src/pkg/runtime/proc.c:290

goroutine 1 [chan receive]:
testing.RunTests(0x400c00, 0x5eda18, 0x1b, 0x1b, 0x1, ...)
	/build/go.tip/go/src/pkg/testing/testing.go:431 +0x898
testing.Main(0x400c00, 0x5eda18, 0x1b, 0x1b, 0x5e93f0, ...)
	/build/go.tip/go/src/pkg/testing/testing.go:327 +0x8a
main.main()
	_/build/go.tip/go/misc/cgo/test/_test/_testmain.go:97 +0x9a

goroutine 34 [syscall]:
_/build/go.tip/go/misc/cgo/test._Cfunc_doAdd(0x60000000a, 0x7f4c4af29c68)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_defun.c:247 +0x2f
_/build/go.tip/go/misc/cgo/test.testCthread(0xc20014b000, 0x42a66c)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:644 +0x2b
_/build/go.tip/go/misc/cgo/test.TestCthread(0xc20014b000, 0x32dc4900)
	/build/go.tip/go/misc/cgo/test/cgo_test.go:38 +0x25
testing.tRunner(0xc20014b000, 0x5edc88, 0x0, 0x0)
	/build/go.tip/go/src/pkg/testing/testing.go:315 +0x6c
created by testing.RunTests
	/build/go.tip/go/src/pkg/testing/testing.go:430 +0x875

goroutine 33 [syscall]:
_/build/go.tip/go/misc/cgo/test._Cfunc_usleep(0x2710, 0xc20008f8c0)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_defun.c:391 +0x2f
created by _/build/go.tip/go/misc/cgo/test.lockOSThreadCallback
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:1123 +0x34
exit status 2
FAIL	_/build/go.tip/go/misc/cgo/test	1.066s

[Patrick Mylund Nielsen]

Distro and kernel version (uname -a)?

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

[Albert Strasheim]

On Thu, Feb 21, 2013 at 11:46 AM, Patrick Mylund Nielsen
<pat...@patrickmylund.com> wrote:
> Distro and kernel version (uname -a)?

We've been here a few times before. :-)

Fedora 16, kernel 3.4.7-1.fc16.x86_64

FreeBSD x64 seems to have a similar problem:

http://build.golang.org/log/dd2e254eea6cea2b21d29f1d4d4afa4f5524205b

[Patrick Mylund Nielsen]

FYI from another thread: should be fixed by https://codereview.appspot.com/7397049

[Albert Strasheim]

Hello

On Friday, February 22, 2013 12:42:29 AM UTC+2, Patrick Mylund Nielsen wrote:

FYI from another thread: should be fixed by https://codereview.appspot.com/7397049

Still seeing the following intermittent failure

go version devel +ca83aeaa55e0 Fri Feb 22 12:23:19 2013 +1100 linux/amd64

GOMAXPROCS=52

./run.bash --no-rebuild

# ../misc/cgo/test
fatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan receive]:
testing.RunTests(0x55ba98, 0x602a90, 0x1b, 0x1b, 0x1, ...)
	/build/go.tip/go/src/pkg/testing/testing.go:427 +0x89b
testing.Main(0x55ba98, 0x602a90, 0x1b, 0x1b, 0x5fe420, ...)
	/build/go.tip/go/src/pkg/testing/testing.go:323 +0x8a
main.main()
	_/build/go.tip/go/misc/cgo/test/_test/_testmain.go:97 +0x9a

goroutine 0 [semacquire]:
_/build/go.tip/go/misc/cgo/test.Add(0x1)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:634 +0x5c

goroutine 33 [syscall]:
_/build/go.tip/go/misc/cgo/test._Cfunc_usleep(0x2710, 0x4198c0)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_defun.c:391 +0x2f
created by _/build/go.tip/go/misc/cgo/test.lockOSThreadCallback
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:1123 +0x34

goroutine 34 [syscall]:
_/build/go.tip/go/misc/cgo/test._Cfunc_doAdd(0x60000000a)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_defun.c:247 +0x2f
_/build/go.tip/go/misc/cgo/test.testCthread(0xc200000240)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:644 +0x2b
_/build/go.tip/go/misc/cgo/test.TestCthread(0xc200000240)
	/build/go.tip/go/misc/cgo/test/cgo_test.go:38 +0x25
testing.tRunner(0xc200000240, 0x602d00)
	/build/go.tip/go/src/pkg/testing/testing.go:311 +0x6f
created by testing.RunTests
	/build/go.tip/go/src/pkg/testing/testing.go:426 +0x878

goroutine 0 [semacquire]:
_/build/go.tip/go/misc/cgo/test.Add(0x1)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:634 +0x5c

goroutine 0 [semacquire]:
_/build/go.tip/go/misc/cgo/test.Add(0x2)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:634 +0x5c

goroutine 0 [running]:

goroutine 0 [semacquire]:
[fp=0x7f5e00650ef0] _/build/go.tip/go/misc/cgo/test.Add(0x0)
	_/build/go.tip/go/misc/cgo/test/_test/_cgo_gotypes.go:634 +0x5c

goroutine 0 [running]:

goroutine 0 [syscall]:

goroutine 0 [syscall]:

goroutine 0 [syscall]:
exit status 2
FAIL	_/build/go.tip/go/misc/cgo/test	1.070s

Cheers

Albert

[Dmitry Vyukov]

I guess we do not account that goroutines in grunning. That would be
if the goroutines do not block and do not decrement grunning.
So we have N normal runnable goroutines and N alien cgo goroutines
that block and as the result grunning == 0.

[Russ Cox]

On Fri, Feb 22, 2013 at 1:59 AM, Dmitry Vyukov <dvy...@google.com> wrote:

I guess we do not account that goroutines in grunning. That would be
if the goroutines do not block and do not decrement grunning.
So we have N normal runnable goroutines and N alien cgo goroutines
that block and as the result grunning == 0.

I didn't do this. Did this get fixed?

Russ 

[Dmitry Vyukov]

It was fixed with the new scheduler.
It does not count grunning, instead it counts mrunning (as a result it
does not report deadlocks with cgo at all because of the extra m).