Comment 1 by dobronszki:

Sorry,
I used the "go run" command on windows, Go1 version.

Comment 2:

There's very little in this bug report for us to act on.  Can you
explain how to reproduce the problem, with actual code?
I don't know what you mean by dependency.  Normally we mean an
explicit import statement, but if you have an import cycle your code
should not compile at all.  If you mean one goroutine waiting on
another, then you should have gotten tracebacks of the goroutines
along with the panic about the deadlock.
Russ

Comment 3 by dobronszki:

In gopath:
cyclic/main.go
 package main
 import(
    "cyclic/a"
 )
 func main() {
 }
cyclic/a/index.go
 package a
 import(
    "cyclic/b"
 )
cyclic/b/index.go
 package b
 import(
     "cyclic/a"
 )
Running "go run cyclic/main.go" on Windows give me:
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan receive]:
main.(*builder).do(0x200bb240, 0x20061a80, 0x0)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/build.go:606 +0x3af
main.runRun(0x810d8c, 0x20075610, 0x1)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/run.go:58 +0x39c
main.main()
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/main.go:141 +0x39c
goroutine 2 [syscall]:
created by runtime.main
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/pkg/runtime/proc.c:221
goroutine 3 [chan receive]:
main._func_005(0x20130300, 0x20130370, 0x0)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/build.go:595 +0x3f
created by main.(*builder).do
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/build.go:603 +0x390
goroutine 4 [chan receive]:
main._func_005(0x20130300, 0x20130370, 0x0)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/build.go:595 +0x3f
created by main.(*builder).do
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist894290290/go/src/cmd/go/build.go:603 +0x390
Which can be a kind of WTF for a lot of people I guess.
Attached zip too.

Attachments:

1. cyclic.zip (662 bytes)

Comment 4 by dobronszki:

"you should have gotten tracebacks of the goroutines
along with the panic about the deadlock"
Yeah, that's what I got when I accidentally introduced a cyclic import to one of my apps
and scratched my head for at least 15 seconds.
I think a more sensical error message like, someting along the lines of "You have just
created a dependency cycle, you retard" would be welcome, because if I would encounter
this exciting novel at 2AM I would frankly punch trough my monitor.

Comment 5:

I tried recreating your test case and I get messages like:
$ go run cyclic/main.go
cyclic/main.go:4:8: import loop
$
Clearly in your case the go command is not diagnosing the import loop,
and then it gets stuck trying to build the program in the right order.
 I am not sure why it is not diagnosing the import loop.  Perhaps
there is a bug involving / vs \ paths.

Labels changed: added priority-soon, removed priority-triage.

Owner changed to builder@golang.org.

Status changed to Accepted.

Comment 6:

It is broken on go1:
C:\a\code\src\cyclic>go run main.go
throw: all goroutines are asleep - deadlock!
goroutine 1 [chan receive]:
main.(*builder).do(0x1120c400, 0x111c18c0, 0x0)
        C:/a/go1/src/cmd/go/build.go:606 +0x3af
main.runRun(0x80ed8c, 0x111c3050, 0x1)
        C:/a/go1/src/cmd/go/run.go:58 +0x39c
main.main()
        C:/a/go1/src/cmd/go/main.go:141 +0x39c
goroutine 2 [syscall]:
created by runtime.main
        C:/a/go1/src/pkg/runtime/proc.c:221
goroutine 3 [chan receive]:
main._func_005(0x112812c0, 0x11281330, 0x0)
        C:/a/go1/src/cmd/go/build.go:595 +0x3f
created by main.(*builder).do
        C:/a/go1/src/cmd/go/build.go:603 +0x390
goroutine 4 [chan receive]:
main._func_005(0x112812c0, 0x11281330, 0x0)
        C:/a/go1/src/cmd/go/build.go:595 +0x3f
created by main.(*builder).do
        C:/a/go1/src/cmd/go/build.go:603 +0x390
C:\a\code\src\cyclic>go version
go version go1
But it looks like it is fixed now:
C:\a\code\src\cyclic>go run main.go
main.go:4:2: import loop
C:\a\code\src\cyclic>go version
go version weekly.2012-03-27 +adc987ffdd99
Do we want to investigate?
Alex

Comment 7 by dobronszki:

Hehe, I will update to the latest weekly (before filing any further bug reports =).

Comment 8:

dobronszki, please let us know if you see any breakages at tip.  I don't know what we
would have done to fix this, which concerns me a little.

Comment 9:

Binary search for the culprit brings me to http://golang.org/cl/6040046. It
sounds like reasonable explanation to me.
Alex

Comment 10:

Great.  I love bugs that we've already fixed.

Comment 11:

Status changed to Fixed.