Issue 1:
What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. http://play.golang.org/p/QSuUU42ggi (It's a minimalish repro based on termbox-go)
2. go run on darwin amd64

What is the expected output?

Do nothing and it should time out after 5 seconds. Spam the keyboard and it should print
out the keys. Hit ctrl+q to quit. This is what it does if I
a) Use go version 1.0.3 or
b) Don't call any variant of Py_Initialize or
c) Run on another OS
d) Use Python 2.7 rather than Python 3.3. The 3.3 version is a universal version
compiled from source in case that matters, but IIRC I saw the same thing with "brew
install python3".

What do you see instead?

Sometimes it gets stuck at the very first "Waiting on signal" log message and
does not time out nor do keyboard input do anything at all. I can usually spam the
keyboard for a second and if it hasn't hung, hit ctrl+q and try again. CPU usage on one
core appears to be at 100%.

Which compiler are you using (5g, 6g, 8g, gccgo)?

gc

Which operating system are you using?

OSX 10.8.3 amd64

Which version are you using? (run 'go version')

21:18 ~/code/3rdparty/termbox/build $ go version
go version devel +b27b1ff18f39 Wed Apr 10 07:15:49 2013 +0200 darwin/amd64

Please provide any additional information below.

21:19 ~/code/3rdparty/termbox/build $ cc --version
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix

21:19 ~/code/3rdparty/termbox/build $ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM
build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If I attach to the hung process with gdb:

(gdb) t a a bt

Thread 5 (Thread 0x1b03 of process 92745):
#0 0x000000000402230b in runtime.mach_semaphore_wait ()
#1 0x0000000004012d2e in runtime.mach_semacquire ()
#2 0x0000000000001d03 in ?? ()
#3 0x0000000000010000 in ?? ()
#4 0x000000000400aff9 in runtime.unlock ()
#5 0x000000c20003c000 in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x0000000004012618 in runtime.semasleep ()
#8 0x0000000000001d03 in ?? ()
#9 0xffffffffffffffff in ?? ()
#10 0x00000000041174a0 in empty_value ()
#11 0x000000000400b19a in runtime.notesleep ()
#12 0xffffffffffffffff in ?? ()
#13 0x0000000000000000 in ?? ()

Thread 4 (Thread 0x1a03 of process 92745):
#0 0x000000000402230b in runtime.mach_semaphore_wait ()
#1 0x0000000004012d2e in runtime.mach_semacquire ()
#2 0x1301010100001b03 in ?? ()
#3 0x000000000400aff9 in runtime.unlock ()
#4 0x000000c20003c000 in ?? ()
#5 0x0000000000000001 in ?? ()
#6 0x0000000000000000 in ?? ()

Thread 3 (Thread 0x1903 of process 92745):
#0 0x000000000402230b in runtime.mach_semaphore_wait ()
#1 0x0000000004012d2e in runtime.mach_semacquire ()
#2 0x1301010100001803 in ?? ()
#3 0x0000000000001000 in ?? ()
#4 0x0000001fb0103e20 in ?? ()
#5 0x00007fff0000000a in ?? ()
#6 0x0000000000000000 in ?? ()

Thread 2 (Thread 0x1803 of process 92745):
#0 0x000000000402230b in runtime.mach_semaphore_wait ()
#1 0x0000000004012d2e in runtime.mach_semacquire ()
#2 0x0000000000001403 in ?? ()
#3 0x0000000000000000 in ?? ()

Thread 1 (Thread 0x1703 of process 92745):
#0 0x000000000401b7d4 in runtime.newstack ()
#1 0x000000000400b19a in runtime.notesleep ()
#2 0xffffffffffffffff in ?? ()
#3 0x0000000000000000 in ?? ()

Issue 2:
by rpzrpzrpz:

[root@rpzcentos rpzcache]# go version
go version go1.3.1 linux/amd64

net.ListenUDP("udp4",@gsrvaddr)
glen,grxadd, gerr := gconn.ReadFromUDP(gbuf[0:])

go funcprocessbytes(grxadd,gbuf[0:glen])

There is no way to call a go routine after calling ReadFromUDP since those bytes are not
safe in the go routine.

The go routine will pass along the proper values in grxadd, but the bytes in gbuf
are sometimes duplicated on successive calls to the funcprocessbytes( ).

Changing the code and removing the "go" directive, the bytes are processed OK
because the bytes are left in the network stack and each call to funcprocessbytes() is
called serially instead of in parallel.

I will try to work on a sample code program for this.