FAQ
Hi all,

I noticed go 1.1 beta sometimes fails to detect deadlock.

This happened in a few occasions where I forgot to Unlock an RWMutex. When
compiled with gc 1.0.3, the runtime properly paniced with "throw: all
goroutines are asleep - deadlock!". With go 1.1 beta, the program just
hung. This already happened on go tip between 1.0.3 and 1.1 beta. I am
running Linux x64.

My project (code.google.com/p/mx3) is rather large and I have not been able
to produce a minimal example with the same erratic behavior. I.e., a
minimal program that locks an RWMutex twice properly throws deadlock even
with go 1.1.

I must add that I call C code, and occasionally use the package "unsafe".
However, I have never experienced segfaults or "unexpected fault address"
panics. So I would be surprised if this were a memory corruption issue.

Did anyone else experience such issue?

Thanks,
-Arne;

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Rémy Oudompheng at Apr 5, 2013 at 12:08 pm
    The deadlock detection only works on trivial examples: between Go 1
    and Go 1.1, the runtime changes have made trivial examples become much
    less trivial.

    If you have a simple example you can open an issue, but in general you
    cannot expect it to detect arbitrary deadlocks.

    Rémy.


    2013/4/5, a.vansteenkiste@gmail.com <a.vansteenkiste@gmail.com>:
    Hi all,

    I noticed go 1.1 beta sometimes fails to detect deadlock.

    This happened in a few occasions where I forgot to Unlock an RWMutex. When
    compiled with gc 1.0.3, the runtime properly paniced with "throw: all
    goroutines are asleep - deadlock!". With go 1.1 beta, the program just
    hung. This already happened on go tip between 1.0.3 and 1.1 beta. I am
    running Linux x64.

    My project (code.google.com/p/mx3) is rather large and I have not been able

    to produce a minimal example with the same erratic behavior. I.e., a
    minimal program that locks an RWMutex twice properly throws deadlock even
    with go 1.1.

    I must add that I call C code, and occasionally use the package "unsafe".
    However, I have never experienced segfaults or "unexpected fault address"
    panics. So I would be surprised if this were a memory corruption issue.

    Did anyone else experience such issue?

    Thanks,
    -Arne;

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • A Vansteenkiste at Apr 5, 2013 at 12:22 pm
    Thanks for the answer Rémy. I got so used to the runtime panicking when all
    goroutines are asleep, that I assumed it should always work. It's good to
    know that there is no such guarantee. Since in simple cases it still works,
    I assume it does not count as an issue. Also it's good to know that I'm
    probably not corrupting memory.

    greets,
    Arne;

    On Friday, April 5, 2013 2:08:29 PM UTC+2, Rémy Oudompheng wrote:

    The deadlock detection only works on trivial examples: between Go 1
    and Go 1.1, the runtime changes have made trivial examples become much
    less trivial.

    If you have a simple example you can open an issue, but in general you
    cannot expect it to detect arbitrary deadlocks.

    Rémy.


    2013/4/5, a.vanst...@gmail.com <javascript:> <a.vanst...@gmail.com<javascript:>>:
    Hi all,

    I noticed go 1.1 beta sometimes fails to detect deadlock.

    This happened in a few occasions where I forgot to Unlock an RWMutex. When
    compiled with gc 1.0.3, the runtime properly paniced with "throw: all
    goroutines are asleep - deadlock!". With go 1.1 beta, the program just
    hung. This already happened on go tip between 1.0.3 and 1.1 beta. I am
    running Linux x64.

    My project (code.google.com/p/mx3) is rather large and I have not been able
    to produce a minimal example with the same erratic behavior. I.e., a
    minimal program that locks an RWMutex twice properly throws deadlock even
    with go 1.1.

    I must add that I call C code, and occasionally use the package "unsafe".
    However, I have never experienced segfaults or "unexpected fault address"
    panics. So I would be surprised if this were a memory corruption issue.

    Did anyone else experience such issue?

    Thanks,
    -Arne;

    --
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Apr 5, 2013 at 4:06 pm
    Hi,

    If you use cgo, then deadlocks won't be detected. Because now C code can
    call back into Go from arbitrary threads. This means that even if Go part
    of the system is completely deadlocked, a C thread that is not under
    control of Go runtime can call info Go and unblock some goroutines (e.g. by
    sending on chan).

    On Fri, Apr 5, 2013 at 4:07 AM, wrote:

    Hi all,

    I noticed go 1.1 beta sometimes fails to detect deadlock.

    This happened in a few occasions where I forgot to Unlock an RWMutex. When
    compiled with gc 1.0.3, the runtime properly paniced with "throw: all
    goroutines are asleep - deadlock!". With go 1.1 beta, the program just
    hung. This already happened on go tip between 1.0.3 and 1.1 beta. I am
    running Linux x64.

    My project (code.google.com/p/mx3) is rather large and I have not been
    able to produce a minimal example with the same erratic behavior. I.e., a
    minimal program that locks an RWMutex twice properly throws deadlock even
    with go 1.1.

    I must add that I call C code, and occasionally use the package "unsafe".
    However, I have never experienced segfaults or "unexpected fault address"
    panics. So I would be surprised if this were a memory corruption issue.

    Did anyone else experience such issue?

    Thanks,
    -Arne;

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedApr 5, '13 at 11:07a
activeApr 5, '13 at 4:06p
posts4
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase