Comment 1:

Please run the program with GOTRACEBACK=2, and then do 'kill -6 PID', and post the stack
traces here.

Comment 3:

go version devel +7afd81b7fe12 Fri Aug 09 21:43:00 2013 +0400 darwin/amd64
$ GOTRACEBACK=2 ./test-network 
Starting request
SIGABRT: abort
PC=0x3c8dc
runtime.notetsleepg(0x3c32bc, 0x7e0e0570, 0x3)
    .../src/pkg/runtime/lock_futex.c:188 +0x40 fp=0x4005ef74
timerproc()
    .../src/pkg/runtime/time.goc:217 +0xfc fp=0x4005efcc
runtime.goexit()
    .../src/pkg/runtime/proc.c:1364 fp=0x4005efcc
created by addtimer
    .../src/pkg/runtime/time.goc:90
goroutine 1 [select]:
runtime.park(0x17b34, 0x1070d310, 0x3bf927)
    .../src/pkg/runtime/proc.c:1312 +0x48
selectgo(0x40050f24)
    .../src/pkg/runtime/chan.c:995 +0x798
runtime.selectgo(0x1070d310)
    .../src/pkg/runtime/chan.c:845 +0x10
main.main()
    test-network.go:20 +0x2f0
runtime.main()
    .../src/pkg/runtime/proc.c:200 +0xf4
runtime.goexit()
    .../src/pkg/runtime/proc.c:1364
goroutine 2 [syscall]:
runtime.notetsleepg(0x4005ffa0, 0xf8475800, 0xd)
    .../src/pkg/runtime/lock_futex.c:188 +0x40
runtime.MHeap_Scavenger()
    .../src/pkg/runtime/mheap.c:467 +0xe4
runtime.goexit()
    .../src/pkg/runtime/proc.c:1364
created by runtime.main
    .../src/pkg/runtime/proc.c:167
goroutine 4 [select]:
runtime.park(0x17b34, 0x1070d460, 0x3bf927)
    .../src/pkg/runtime/proc.c:1312 +0x48
selectgo(0x4005dd04)
    .../src/pkg/runtime/chan.c:995 +0x798
runtime.selectgo(0x1070d460)
    .../src/pkg/runtime/chan.c:845 +0x10
net/http.(*Transport).getConn(0x107460c0, 0x1071d800, 0x1071d800, 0x0, 0x0)
    .../src/pkg/net/http/transport.go:424 +0x228
net/http.(*Transport).RoundTrip(0x107460c0, 0x1070d380, 0x0, 0x0, 0x0)
    .../src/pkg/net/http/transport.go:182 +0x2bc
net/http.send(0x1070d380, 0x4000c270, 0x107460c0, 0x0, 0x0, ...)
    .../src/pkg/net/http/client.go:168 +0x328
net/http.(*Client).send(0x3c3260, 0x1070d380, 0x16, 0x0, 0x0)
    .../src/pkg/net/http/client.go:100 +0x10c
net/http.(*Client).doFollowingRedirects(0x3c3260, 0x1070d380, 0x227ab0, 0x0, 0x0, ...)
    .../src/pkg/net/http/client.go:294 +0x5bc
net/http.(*Client).Get(0x3c3260, 0x1fd948, 0x16, 0x0, 0x0, ...)
    .../src/pkg/net/http/client.go:248 +0xb0
net/http.Get(0x1fd948, 0x16, 0x0, 0x0, 0x0)
    .../src/pkg/net/http/client.go:225 +0x50
main.func·001()
    test-network.go:14 +0x44
runtime.goexit()
    .../src/pkg/runtime/proc.c:1364
created by main.main
    test-network.go:19 +0x148
goroutine 5 [running]:
    goroutine running on other thread; stack unavailable
created by net/http.(*Transport).getConn
    .../src/pkg/net/http/transport.go:421 +0x118
trap    0x0
error   0x0
oldmask 0x0
r0      0xfffffffc
r1      0x0
r2      0x0
r3      0x4005ef28
r4      0x0
r5      0x0
r6      0x0
r7      0xf0
r8      0x3b9aca00
r9      0x3c6290
r10     0x107016e0
fp      0x0
ip      0x1070d310
sp      0x4005ef0c
lr      0x259e4
pc      0x3c8dc
cpsr    0x20000010
fault   0x0

Comment 4:

Does it consume 100% CPU when hangs?

Comment 5:

I suspect that it's infinitely looping inside of fdMutex. Is it possible to attach gdb
and see where exactly it loops? and also what is the state of fdMutex?

Comment 6:

perhaps related, issue #6440.

Comment 7:

what's your kernel version?
could you please cross compile test for sync/atomic and run it like this on your arm
platform?
./atomic.test -test.v 
does it immediate hang without much output?

Comment 8:

> Does it consume 100% CPU when hangs?
Yes.
> I suspect that it's infinitely looping inside of fdMutex. Is it possible to attach gdb
and see where exactly it loops? and also what is the state of fdMutex?
I don't have gdb available in this environment. I can arrange it, but it'll take a
while. Let me know if it is worth doing.

Comment 9:

> what's your kernel version?
$ uname -a
Linux ppbeacon 2.6.35.3-670-g914558e #1 PREEMPT Thu Aug 15 09:55:00 PDT 2013 armv5tejl
GNU/Linux
> could you please cross compile test for sync/atomic and run it like this on your arm
platform?
> does it immediate hang without much output?
Yes, it hangs immediately and pegs the CPU.

Comment 10:

thank you, it is indeed issue #6440.

Status changed to Duplicate.

Merged into issue #6440.

Comment 11:

phew!

Comment 12:

:)

Comment 13:

ps: one workaround is to upgrade the kernel to 3.x series so that it will use kernel
provided 64-bit atomic op.

Comment 14:

Good to know; thanks. Alas, that's not viable for me right now for other reasons, but
hopefully that'll help future issue spelunkers.