Was able to reproduce the go1.12beta2 hang / segfault on a different mac:
gohangs.txt
as well as on a linux VM - there it dies after go: extracting git.ouroath.com/mirror-github/gogo--protobuf v1.2.0:
gohangs-linux.txt

here's the time it takes to segfault on Linux:

real	1m54.256s
user	2m46.670s
sys	0m39.145s

On my Mac, go mod tidy now hangs for around 30min. - still at go: extracting git.ouroath.com/mirror-github/jmespath--go-jmespath v0.0.0-20180206000000-c2b33e8439af944379acbdd9c3a5fe0bc44bd8a5

Can you show us the repo where this crash is happening so that we can diagnose this issue faster ?

I wish I could - it is an internal project... I attach a slightly modified go.mod file, maybe it could help. I can reliably reproduce the crash - let me know if I can run some experiments etc. I'm building no the master version of go from the source and will try to see if the crash happens with the HEAD version as well. Can I save the state (cache directories - only ~/go/pkg?) to be able to restore the environment?

gomod.txt

was able to reproduce hang/crash with HEAD as well as go1.12beta1

@agnivade - I added a debugger to src/cmd/go/internal/modcmd/tidy.go in modTidyGoSum to print the values of m and r (Replacement) modules, and pass a recursive call depth counter (diff attached). I'm attaching a snippet of the output from running go mod tidy -v - call depth shows now 120776 after a couple of minutes runtime - seems like an infinite loop.

tidy.go.diff.txt
out-small.txt

/cc @bcmills

when I added a seen map to guard against reprocessing the module, the hanging stopped and go mod tidy returned quickly as usual (actually probably need to guard on the Path+Version combination)

+       var walk func(module.Version, int64)
+       seen := map[string]bool{}
+       walk = func(m module.Version, depth int64) {
+               if seen[m.Path] {
+                       fmt.Fprintf(os.Stderr, "DMDEBUG ALREADY seen module Path %s, Version %s - return, depth=%d\n", m.Path, m.Version, depth)
+                       return
+               }
+               seen[m.Path] = true

Thanks for the report. The bug is (sadly) pretty clear: we're storing the replaced directory in the keep map, but using the unreplaced path in the cycle check that uses it.

Here's a simple reproducer:

scratch$ mkdir -p ./cycle-a ./cycle-b

scratch$ cat >./cycle-a/a.go <<EOF
package a
EOF

scratch$ cat >./cycle-a/go.mod <<EOF
module golang.org/issue/cycle-a

go 1.12

require golang.org/issue/cycle-b v0.0.0
replace golang.org/issue/cycle-b => ./cycle-b
EOF

scratch$ cat >./main.go <<EOF
package main

import (
        _ "golang.org/issue/cycle-a"
        _ "golang.org/issue/cycle-b"
)
EOF

scratch$ cat >./go.mod <<EOF
module golang.org/issue/scratch

go 1.12

replace golang.org/issue/cycle-a => ./cycle-a

replace golang.org/issue/cycle-b => ./cycle-b

require (
        golang.org/issue/cycle-a v0.0.0
        golang.org/issue/cycle-b v0.0.0
)
EOF

scratch$ cat >./cycle-b/b.go <<EOF
package b
EOF

scratch$ cat >./cycle-b/go.mod <<EOF
module golang.org/issue/cycle-b

go 1.12

require golang.org/issue/cycle-a v0.0.0
replace golang.org/issue/cycle-a => ./cycle-a
EOF

scratch$ export GOTRACEBACK=none

scratch$ go mod tidy
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow

Change https://golang.org/cl/161917 mentions this issue: cmd/go/internal/modcmd: fix go mod tidy hangs

Change https://golang.org/cl/161898 mentions this issue: cmd/go/internal/modcmd: use replaced paths to break cycles in 'go mod tidy'