deadlock with a empty select{} in main goroutine.

477 views
Skip to first unread message

aravind...@gmail.com

unread,
Apr 8, 2020, 12:17:59 PM4/8/20
to golang-nuts

Hi All,

I am not able to understand why this piece of go code  deadlocks.
Doesn't empty select{} blocks forever, irrespective of other go routines  to wake that up.


Please help me to understand why code is detected as deadlock.
And When I run this code with go run -race main.go in Linux box(go version go1.13.6 linux/amd64), it prints "received 5" waits forever.
I expect same to happen, when built and run.

Sorry, if this is already answered, please point me.

Thanks ,
Aravindhan K

Manlio Perillo

unread,
Apr 8, 2020, 12:27:17 PM4/8/20
to golang-nuts
On Wednesday, April 8, 2020 at 6:17:59 PM UTC+2, aravind...@gmail.com wrote:

Hi All,

I am not able to understand why this piece of go code  deadlocks.
Doesn't empty select{} blocks forever, irrespective of other go routines  to wake that up.



The error message is very clear:
"fatal error: all goroutines are asleep - deadlock!"

The problem is that **all** the goroutines are waiting forever.

Manlio 

burak serdar

unread,
Apr 8, 2020, 12:30:14 PM4/8/20
to aravind...@gmail.com, golang-nuts
On Wed, Apr 8, 2020 at 10:17 AM <aravind...@gmail.com> wrote:
>
>
> Hi All,
>
> I am not able to understand why this piece of go code deadlocks.
> Doesn't empty select{} blocks forever, irrespective of other go routines to wake that up.
>
> https://play.golang.org/p/zBWZPjTGYX7
>
> Please help me to understand why code is detected as deadlock.

There is one goroutine, the main one, waiting on a select and there
are no other goroutines that can do anything to let that goroutine
progress. That's a deadlock. If the other goroutines were in a loop
sending-receiving messages, it wouldn't be a deadlock.

> And When I run this code with go run -race main.go in Linux box(go version go1.13.6 linux/amd64), it prints "received 5" waits forever.
> I expect same to happen, when built and run.
>
> Sorry, if this is already answered, please point me.
>
> Thanks ,
> Aravindhan K
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/5eeffc06-15e6-47d8-a662-43746f2e8fe5%40googlegroups.com.

Ian Lance Taylor

unread,
Apr 8, 2020, 12:30:18 PM4/8/20
to aravind...@gmail.com, golang-nuts
Is your question why the behavior is different when you use -race?
The deadlock detection is best-effort; there are many different ways
that it can fail to detect a deadlock. I expect that -race interferes
with the simple deadlock detection.

Ian

Vikram Ingawale

unread,
Apr 8, 2020, 12:44:11 PM4/8/20
to Manlio Perillo, golang-nuts
Hi Manlio ,

The select statement will block until one of its cases is executed and in your program the select statement doesn't have any cas. so it will block forever and resulting in deadlock


Thanks,
Vikram Ingawale
ph : +91 9766984458


--
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.

Aravindhan K

unread,
Apr 8, 2020, 1:19:54 PM4/8/20
to Vikram Ingawale, Manlio Perillo, golang-nuts
Thanks all.

If that is the case, in below code main go routine will a reach a situation where no other go routines running to wake it up.
But no deadlock is not detected.
May I assume deadlock - detection couldn't pick up this scenario?
By using empty select{}, doesn't the coder purposely wishes to block forever?

Thanks, Aravindhan K




Ian Lance Taylor

unread,
Apr 8, 2020, 5:52:14 PM4/8/20
to Aravindhan K, Vikram Ingawale, Manlio Perillo, golang-nuts
On Wed, Apr 8, 2020 at 10:19 AM Aravindhan K <aravind...@gmail.com> wrote:
>
> If that is the case, in below code main go routine will a reach a situation where no other go routines running to wake it up.
> But no deadlock is not detected.
> https://play.golang.org/p/z1NMYQAi0KY
> May I assume deadlock - detection couldn't pick up this scenario?
> By using empty select{}, doesn't the coder purposely wishes to block forever?

In general the deadlock detector fails in programs that use the
network, because those programs generally have background goroutines,
created by the runtime package, that wait for network activity. So
the deadlock detector thinks that the program is not deadlocked, but
just sleeping waiting for something to happen on the network.

Yes, select{} implies that that particular goroutines will block
forever, but that doesn't mean that all other goroutines will block.

Ian
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAJn1S2Ob8R1hW2ix3cp2Sd9FOgzM0jcdEsr97suXshEAHSdtoQ%40mail.gmail.com.

Aravindhan K

unread,
Apr 8, 2020, 11:17:06 PM4/8/20
to Ian Lance Taylor, Vikram Ingawale, Manlio Perillo, golang-nuts
Thanks Ian.

Aravindhan K
Reply all
Reply to author
Forward
0 new messages