text:
playground: ParseFile example at godoc.org cannot be run

example_test.go is used for Go example output test.
Is there anyway to make this runnable on golang.org?
If not, please feel free to close this.
Thanks!

What version of Go are you using (go version)?

https://golang.org/pkg/go/parser/#example_ParseFile

What operating system and processor architecture are you using (go env)?

https://golang.org/pkg/go/parser/#example_ParseFile

What did you do?
If possible, provide a recipe for reproducing the error.

Hit run button at  https://golang.org/pkg/go/parser/#example_ParseFile

What did you expect to see?

No error.

What did you see instead?

open example_test.go: No such file or directory

I'm not sure what we can do about this, but perhaps somebody will have an idea.

So in a weird twist, it seems like by the time that a snippet's Run is triggered, it has been removed from the file system or at least it isn't in the place that it reports being called from see https://play.golang.org/p/QJrwR06lnA or
package main

import (
	"fmt"
	"os"
	"path/filepath"
	"runtime"
)

func callerSourcePath() string {
	_, callerPath, _, _ := runtime.Caller(1)
	return callerPath
}

func main() {
	// Will walk up to the root from the call site of this file
	curPath := callerSourcePath()
	fmt.Printf("This file location is %q, attempt to walk up the root\n", curPath)
	for {
		if curPath == "" || curPath == "/" {
			break
		}
		fmt.Printf("walking to %v ", curPath)
		f, err := os.Open(curPath)
		fmt.Printf("\n\tpath %s exists=%v(f=%v) err=%v\n", curPath, f != nil, f, err)
		if f != nil {
			_ = f.Close()
		}
		curPath = filepath.Dir(curPath)
	}
}

when run on the playground shows that only /tmp exists but the file that it is purported to exist in cannot be found
This file location is "/tmp/sandbox025674958/main.go", attempt to walk up the root
walking to /tmp/sandbox025674958/main.go
	path /tmp/sandbox025674958/main.go exists=false(f=<nil>) err=open /tmp/sandbox025674958/main.go: No such file or directory
walking to /tmp/sandbox025674958
	path /tmp/sandbox025674958 exists=false(f=<nil>) err=open /tmp/sandbox025674958: No such file or directory
walking to /tmp
	path /tmp exists=true(f=&{0x10434210}) err=<nil>

I came to this conclusion by stripping down os.Open down to the nacl implementation of syscall and running that raw implementation on the playground itself. Please see https://play.golang.org/p/9fMAPM6lNc
which produces
<nil> stat /tmp/sandbox890988319/main.go: No such file or directory

You (intentionally) cannot read files, which you didn't create before in the playground.
see https://play.golang.org/p/hORbzSS4NT for an example.

The tmp source file is created in another world (outside the nacl runtime)
and so the program cannot access it.

@nightlyone true, yap I tested that out too last night.
@minux ahh I see, could you please point me to a place I can see how this is done or might it be documented? I'll take a look at setting up my nacl environment locally then inspect it.
In relation to @nightlyone's comment, does this mean that the unintended consequence of intentionally sandboxing is that all godoc snippets whose underlying functionality involves the use of os.Open or even os.Stat(since these files were not created by the user) won't work on nacl?

authors: gyuho ianlancetaylor minux nightlyone odeke-em


text:
cmd/go: TestRepoRootForImportPath fails

At tip:
$ go test cmd/go
--- FAIL: TestRepoRootForImportPath (0.92s)
	vcs_test.go:159: RepoRootForImport("git.openstack.org/openstack/swift.git"): invalid version control suffix in git.openstack.org path
FAIL
FAIL	cmd/go	207.939s

This test doesn't run in -short mode, which is probably why no one noticed. (We could really use a builder that runs the full tests.)

As far as I can see, this test has been broken since it was submitted in https://golang.org/cl/23135, but nobody noticed because the test does not run with -test.short as used on the builders.
I asked on the CL what the intent is.

Bother. I'll jump on this right away - sorry.

Any status update, @emonty?

Should be fixed by afccfb829f17f85a8d4aa74f1a11a27422437405.

source: gharchive/issue

authors: adg emonty ianlancetaylor josharian

repo: golang/go

license_type: permissive

license_source: github-api


text:
proposal: add flag to go-get to check GPG signed commits

Installing packages in Go community is often described as
go get https://url/to/some/repo.git

but it doesn't seem very secure.
It would be nice to have go get flag to check if HEAD of downloaded repo was signed with trusted GPG key.

It would for example help in case of hijacked repository names (from what I've heard it's common in node community).

trusted GPG key

How to determine which GPG key is trusted for repository?

I feel like this is probably a job for the dependency/vendoring tools instead of the super-simple "go get".
/cc @adg @spf13

Then why go get have flags like -u? Without such protection -u can be
insecure.
2016-11-18 15:12 GMT+01:00 Brad Fitzpatrick notifications@github.com:

I feel like this is probably a job for the dependency/vendoring tools
instead of the super-simple "go get".
/cc @adg https://github.com/adg @spf13 https://github.com/spf13
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17977#issuecomment-261540360, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA6jxbRjaIH95cjmpWXzsPlGeu9n1VLHks5q_bJPgaJpZM4K2fXA
.

For the same reason that online payments are insecure over HTTP and sufficiently secure over HTTPS.
Furthermore, go get cannot require a signed tag to exist, because that is not the case for the majority of repositories out there. However, if it doesn't require it, the check would be prone to a simple downgrade attack. If I am able to hijack an HTTPS connection and inject a tampered repository, I could just strip all signed tags.

@dominikh please, read carefully my proposal.
You say:

require

My proposal says:

flag

You say:

I could just strip all signed tags

My proposal says:

HEAD [...] was signed with trusted GPG key

In that case it would fail, because HEAD woudn't be signed with trusted GPG key.

You also said -u. I really don't think we should be introducing even more modes of operation for the tool. Besides, you haven't addressed @ernado's point yet: How does go get know what the right GPG key is? I can sign my hijacked repository, too.
This really isn't go get's job. go get is also not meant to be everything to everyone. It's an easy way of downloading Go packages. More advanced use cases may need other tools.

As for @ernado 's point , it can be for example taken from git-log for just HEAD (git somehow checks this with local GPG store).
So I should rephrase my proposal to:
Mention in go-get documentation that it's not secure.?

it can be for example taken from git-log for just HEAD (git somehow checks this with local GPG store).

That will give you a key. It will not tell you whether the key belongs to Alice or Mallory. Unless you're implying that all the trusted people in your keyring are allowed to hijack each other's repositories.

So I should rephrase my proposal to:
Mention in go-get documentation that it's not secure.?

Only if you make the same suggestion to every website using HTTPS. You could also consider using git clone manually if your environment is so special or compromised that extra security is warranted.

I don't think that comment would be helpful to anybody, but if you want to propose some new wording for the docs that clarify what "go get" does, that might be OK.
If there is a standard way to verify a git repository, one used by several different tools, then perhaps "go get" should implement that.  This is not an area where "go get" should be innovating.

@dominikh what does HTTPS has to do with it?
Let's imagine that scenario:
User X has library Y. He has bad day, writes something rude and his account gets removed from GitHub. Malicious Z then creates account name X with library Y + his own mailicous commit. Meanwhile some Gopher tries to upgrade his dependencies and boom.

The "secure" in go get refers to the transport, not to there are absolutely no ways of impersonating someone else. And the transport is sufficiently secure.
If you're concerned about these attack vectors, I would recommend not blindly executing code in the first place. GPG keys can be stolen as well. People can be coerced into doing things they wouldn't do otherwise. No mechanism in go get is going to protect you from all ways of injecting bad code. go get makes sure that the transport itself cannot be (easily) hijacked.

We should make the default secure, because if we add a flag to check keys,
then it's up to user and most likely people will ignore it. However, there
is no way the command can know the correct gpg key for a repository (keep
in mind that it can't trust the content in the repository as history can be
easily rewritten), so this kind of security is impossible to be made the
default setting.
I think the reason behind this proposal is hypothetical and doesn't have
generic solutions yet, so it's not the Go command responsibility to solve
such hypothetical problems. If you care, manually clone and check the
repository or invent some other tools to do that.

hypothetical

No, it's real-life problem that already was exploited in some package
managers, eg. in Node: https://news.ycombinator.com/item?id=11343985
2016-11-19 2:20 GMT+01:00 Minux Ma notifications@github.com:

We should make the default secure, because if we add a flag to check keys,
then it's up to user and most likely people will ignore it. However, there
is no way the command can know the correct gpg key for a repository (keep
in mind that it can't trust the content in the repository as history can be
easily rewritten), so this kind of security is impossible to be made the
default setting.
I think the reason behind this proposal is hypothetical and doesn't have
generic solutions yet, so it's not the Go command responsibility to solve
such hypothetical problems. If you care, manually clone and check the
repository or invent some other tools to do that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/17977#issuecomment-261682367, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA6jxafUmJCpaJY5hKYJokfqBM1ujwKSks5q_k74gaJpZM4K2fXA
.

Go pulls directly from src control. If you loose control of your repo or vanity domain, that's on you. The best go could do would be for the future pkg manager to write down the pkg checksum at a given revision and check it on pull. Or do what banks or hashicorp do and review any code that comes in regardless of the source.

This seems like a good thing for vendoring tools to experiment with. If there is consensus on a problem to solve and additional steps needed, we could then adopt them into the go command. As of now, there does not seem to be evidence here of consensus on either. Thoughts?

It sounds like we should decline this proposal pending further experimentation by other tools. If a consensus does form, please file a new proposal.

authors: Marqin bradfitz dominikh ernado ianlancetaylor kardianos minux rsc


text:
runtime: TestRWMutex is flaky?

Please answer these questions before submitting your issue. Thanks!
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
for i in `seq 100`; do go test -v runtime -run "TestRWMutex"; done

What did you expect to see?
PASS * 100
What did you see instead?
=== RUN   TestRWMutex
SIGQUIT: quit
PC=0x10625b6 m=2 sigcode=0

goroutine 0 [idle]:
runtime.usleep(0x8b00002710, 0x0, 0x68c71d5b2f, 0x45d964b800, 0x271000000000, 0x8bb25b57c4, 0x45d964b800, 0x3, 0x0, 0x68c71d5b2f, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:323 +0x36 fp=0x700006055de0 sp=0x700006055dc0 pc=0x10625b6
runtime.sysmon()
	/Users/hiro/go/src/runtime/proc.go:3799 +0xa8 fp=0x700006055e68 sp=0x700006055de0 pc=0x1039a08
runtime.mstart1()
	/Users/hiro/go/src/runtime/proc.go:1172 +0x11e fp=0x700006055e90 sp=0x700006055e68 pc=0x103285e
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1142 +0x64 fp=0x700006055ea8 sp=0x700006055e90 pc=0x1032734

goroutine 1 [chan receive]:
runtime.gopark(0x131a290, 0xc420076418, 0x1308f6e, 0xc, 0xc420051b17, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc420051ac8 sp=0xc420051a98 pc=0x102fa7c
runtime.goparkunlock(0xc420076418, 0x1308f6e, 0xc, 0xc4200e8017, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc420051b08 sp=0xc420051ac8 pc=0x102fb6e
runtime.chanrecv(0xc4200763c0, 0x0, 0xc420051b01, 0x10ebc14)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc420051bb8 sp=0xc420051b08 pc=0x1005dc4
runtime.chanrecv1(0xc4200763c0, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc420051be8 sp=0xc420051bb8 pc=0x1005a6b
testing.(*T).Run(0xc4200e2000, 0x130879c, 0xb, 0x131b2e0, 0x108f201)
	/Users/hiro/go/src/testing/testing.go:801 +0x332 fp=0xc420051c98 sp=0xc420051be8 pc=0x10ebc32
testing.runTests.func1(0xc4200e2000)
	/Users/hiro/go/src/testing/testing.go:1053 +0x64 fp=0xc420051ce8 sp=0xc420051c98 pc=0x10efd04
testing.tRunner(0xc4200e2000, 0xc420051d98)
	/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc420051d10 sp=0xc420051ce8 pc=0x10eb8a0
testing.runTests(0xc42000c300, 0x1498000, 0xd7, 0xd7, 0x5f)
	/Users/hiro/go/src/testing/testing.go:1051 +0x2d8 fp=0xc420051dc8 sp=0xc420051d10 pc=0x10ed688
testing.(*M).Run(0xc420051f18, 0x12474b6)
	/Users/hiro/go/src/testing/testing.go:932 +0x111 fp=0xc420051ec0 sp=0xc420051dc8 pc=0x10ec031
runtime_test.TestMain(0xc420051f18)
	/Users/hiro/go/src/runtime/crash_test.go:28 +0x2f fp=0xc420051f10 sp=0xc420051ec0 pc=0x1216c9f
main.main()
	runtime/_test/_testmain.go:902 +0xdb fp=0xc420051f80 sp=0xc420051f10 pc=0x126701b
runtime.main()
	/Users/hiro/go/src/runtime/proc.go:185 +0x20d fp=0xc420051fe0 sp=0xc420051f80 pc=0x102f5dd
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420051fe8 sp=0xc420051fe0 pc=0x10612f1

goroutine 2 [force gc (idle)]:
runtime.gopark(0x131a290, 0x149a0c0, 0x130a49c, 0xf, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002c768 sp=0xc42002c738 pc=0x102fa7c
runtime.goparkunlock(0x149a0c0, 0x130a49c, 0xf, 0xc420000114, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002c7a8 sp=0xc42002c768 pc=0x102fb6e
runtime.forcegchelper()
	/Users/hiro/go/src/runtime/proc.go:235 +0xcc fp=0xc42002c7e0 sp=0xc42002c7a8 pc=0x102f89c
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002c7e8 sp=0xc42002c7e0 pc=0x10612f1
created by runtime.init.4
	/Users/hiro/go/src/runtime/proc.go:224 +0x35

goroutine 3 [GC sweep wait]:
runtime.gopark(0x131a290, 0x149a3c0, 0x130941f, 0xd, 0x1021014, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002cf60 sp=0xc42002cf30 pc=0x102fa7c
runtime.goparkunlock(0x149a3c0, 0x130941f, 0xd, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002cfa0 sp=0xc42002cf60 pc=0x102fb6e
runtime.bgsweep(0xc420020070)
	/Users/hiro/go/src/runtime/mgcsweep.go:52 +0xa3 fp=0xc42002cfd8 sp=0xc42002cfa0 pc=0x10210d3
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002cfe0 sp=0xc42002cfd8 pc=0x10612f1
created by runtime.gcenable
	/Users/hiro/go/src/runtime/mgc.go:216 +0x58

goroutine 4 [finalizer wait]:
runtime.gopark(0x131a290, 0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002d700 sp=0xc42002d6d0 pc=0x102fa7c
runtime.goparkunlock(0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002d740 sp=0xc42002d700 pc=0x102fb6e
runtime.runfinq()
	/Users/hiro/go/src/runtime/mfinal.go:175 +0xb8 fp=0xc42002d7e0 sp=0xc42002d740 pc=0x1017ed8
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002d7e8 sp=0xc42002d7e0 pc=0x10612f1
created by runtime.createfing
	/Users/hiro/go/src/runtime/mfinal.go:156 +0x62

goroutine 5 [syscall]:
runtime.notetsleepg(0x14ba2c0, 0xffffffffffffffff, 0x0)
	/Users/hiro/go/src/runtime/lock_sema.go:280 +0x4b fp=0xc42002df80 sp=0xc42002df40 pc=0x10119eb
os/signal.signal_recv(0x0)
	/Users/hiro/go/src/runtime/sigqueue.go:131 +0xa7 fp=0xc42002dfa8 sp=0xc42002df80 pc=0x1045807
os/signal.loop()
	/Users/hiro/go/src/os/signal/signal_unix.go:22 +0x22 fp=0xc42002dfe0 sp=0xc42002dfa8 pc=0x10e4232
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002dfe8 sp=0xc42002dfe0 pc=0x10612f1
created by os/signal.init.0
	/Users/hiro/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 6 [select, locked to thread]:
runtime.gopark(0x131a2d8, 0x0, 0x1306abf, 0x6, 0x18, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42003aca0 sp=0xc42003ac70 pc=0x102fa7c
runtime.selectgo(0xc42003af50, 0xc420076180)
	/Users/hiro/go/src/runtime/select.go:395 +0x1138 fp=0xc42003af18 sp=0xc42003aca0 pc=0x103fff8
runtime.ensureSigM.func1()
	/Users/hiro/go/src/runtime/signal_unix.go:511 +0x1fe fp=0xc42003afe0 sp=0xc42003af18 pc=0x105da9e
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42003afe8 sp=0xc42003afe0 pc=0x10612f1
created by runtime.ensureSigM
	/Users/hiro/go/src/runtime/signal_unix.go:494 +0xda

goroutine 7 [chan receive]:
runtime.gopark(0x131a290, 0xc42005e358, 0x1308f6e, 0xc, 0xc420024117, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002ee80 sp=0xc42002ee50 pc=0x102fa7c
runtime.goparkunlock(0xc42005e358, 0x1308f6e, 0xc, 0x17, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002eec0 sp=0xc42002ee80 pc=0x102fb6e
runtime.chanrecv(0xc42005e300, 0x0, 0x1, 0x0)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002ef70 sp=0xc42002eec0 pc=0x1005dc4
runtime.chanrecv1(0xc42005e300, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002efa0 sp=0xc42002ef70 pc=0x1005a6b
testing.(*M).before.func1(0xc42005e300)
	/Users/hiro/go/src/testing/testing.go:1111 +0x38 fp=0xc42002efd8 sp=0xc42002efa0 pc=0x10efd98
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002efe0 sp=0xc42002efd8 pc=0x10612f1
created by testing.(*M).before
	/Users/hiro/go/src/testing/testing.go:1110 +0x191

goroutine 8 [chan receive]:
runtime.gopark(0x131a290, 0xc420106058, 0x1308f6e, 0xc, 0xc42002f617, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002f5e8 sp=0xc42002f5b8 pc=0x102fa7c
runtime.goparkunlock(0xc420106058, 0x1308f6e, 0xc, 0x1010f0120104017, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002f628 sp=0xc42002f5e8 pc=0x102fb6e
runtime.chanrecv(0xc420106000, 0x0, 0xc42002f701, 0x1249879)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002f6d8 sp=0xc42002f628 pc=0x1005dc4
runtime.chanrecv1(0xc420106000, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002f708 sp=0xc42002f6d8 pc=0x1005a6b
runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8)
	/Users/hiro/go/src/runtime/rwmutex_test.go:103 +0x1eb fp=0xc42002f770 sp=0xc42002f708 pc=0x12498ab
runtime_test.TestRWMutex(0xc4200e20f0)
	/Users/hiro/go/src/runtime/rwmutex_test.go:118 +0x12f fp=0xc42002f7a8 sp=0xc42002f770 pc=0x1249a0f
testing.tRunner(0xc4200e20f0, 0x131b2e0)
	/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc42002f7d0 sp=0xc42002f7a8 pc=0x10eb8a0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002f7d8 sp=0xc42002f7d0 pc=0x10612f1
created by testing.(*T).Run
	/Users/hiro/go/src/testing/testing.go:800 +0x314

goroutine 50 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1

goroutine 51 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 52 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010efc0 sp=0xc42010efb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010efc8 sp=0xc42010efc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 53 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010f7c0 sp=0xc42010f7b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010f7c8 sp=0xc42010f7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 54 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 55 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 56 [runnable]:
runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:71 fp=0xc420110fc0 sp=0xc420110fb8 pc=0x1249540
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420110fc8 sp=0xc420110fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:97 +0x16d

goroutine 57 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4201117c0 sp=0xc4201117b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201117c8 sp=0xc4201117c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 58 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc420111fc0 sp=0xc420111fb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420111fc8 sp=0xc420111fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 59 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4200f47c0 sp=0xc4200f47b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f47c8 sp=0xc4200f47c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 60 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010afc0 sp=0xc42010afb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010afc8 sp=0xc42010afc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 61 [runnable]:
runtime.(*RWMutex).RUnlock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010b7c8 sp=0xc42010b7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

rax    0x4
rbx    0x3
rcx    0x700006055dc0
rdx    0x0
rdi    0x0
rsi    0x0
rbp    0x700006055dd0
rsp    0x700006055dc0
r8     0x700006055dc0
r9     0x8
r10    0x0
r11    0x246
r12    0x3b4a277fed96
r13    0xb03
r14    0x10326d0
r15    0x1602620
rip    0x10625b6
rflags 0x247
cs     0x7
fs     0x0
gs     0x0
*** Test killed with quit: ran too long (10m0s).
FAIL	runtime	600.024s

Does this issue reproduce with the latest release (go1.8.3)?
System details
go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hiro/.go"
GORACE=""
GOROOT="/Users/hiro/go"
GOTOOLDIR="/Users/hiro/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wq/dwn8hs0x7njbzty9f68y61700000gn/T/go-build091579411=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 X:framepointer
uname -v: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73
lldb --version: lldb-370.0.42
  Swift-3.1
gdb --version: GNU gdb (GDB) 7.12.1

FWIW, sync.TestRWMutex doesn't fail.

Does this pass in 1.8.3? If yes, can you please try bisecting.
On Wed, Jul 5, 2017 at 9:53 AM, hirochachacha notifications@github.com
wrote:

Please answer these questions before submitting your issue. Thanks!
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
for i in seq 100; do go test -v runtime -run "TestRWMutex"; done
What did you expect to see?
PASS * 100
What did you see instead?
=== RUN   TestRWMutex
SIGQUIT: quit
PC=0x10625b6 m=2 sigcode=0
goroutine 0 [idle]:
runtime.usleep(0x8b00002710, 0x0, 0x68c71d5b2f, 0x45d964b800, 0x271000000000, 0x8bb25b57c4, 0x45d964b800, 0x3, 0x0, 0x68c71d5b2f, ...)
/Users/hiro/go/src/runtime/sys_darwin_amd64.s:323 +0x36 fp=0x700006055de0 sp=0x700006055dc0 pc=0x10625b6
runtime.sysmon()
/Users/hiro/go/src/runtime/proc.go:3799 +0xa8 fp=0x700006055e68 sp=0x700006055de0 pc=0x1039a08
runtime.mstart1()
/Users/hiro/go/src/runtime/proc.go:1172 +0x11e fp=0x700006055e90 sp=0x700006055e68 pc=0x103285e
runtime.mstart()
/Users/hiro/go/src/runtime/proc.go:1142 +0x64 fp=0x700006055ea8 sp=0x700006055e90 pc=0x1032734
goroutine 1 [chan receive]:
runtime.gopark(0x131a290, 0xc420076418, 0x1308f6e, 0xc, 0xc420051b17, 0x3)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc420051ac8 sp=0xc420051a98 pc=0x102fa7c
runtime.goparkunlock(0xc420076418, 0x1308f6e, 0xc, 0xc4200e8017, 0x3)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc420051b08 sp=0xc420051ac8 pc=0x102fb6e
runtime.chanrecv(0xc4200763c0, 0x0, 0xc420051b01, 0x10ebc14)
/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc420051bb8 sp=0xc420051b08 pc=0x1005dc4
runtime.chanrecv1(0xc4200763c0, 0x0)
/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc420051be8 sp=0xc420051bb8 pc=0x1005a6b
testing.(*T).Run(0xc4200e2000, 0x130879c, 0xb, 0x131b2e0, 0x108f201)
/Users/hiro/go/src/testing/testing.go:801 +0x332 fp=0xc420051c98 sp=0xc420051be8 pc=0x10ebc32
testing.runTests.func1(0xc4200e2000)
/Users/hiro/go/src/testing/testing.go:1053 +0x64 fp=0xc420051ce8 sp=0xc420051c98 pc=0x10efd04
testing.tRunner(0xc4200e2000, 0xc420051d98)
/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc420051d10 sp=0xc420051ce8 pc=0x10eb8a0
testing.runTests(0xc42000c300, 0x1498000, 0xd7, 0xd7, 0x5f)
/Users/hiro/go/src/testing/testing.go:1051 +0x2d8 fp=0xc420051dc8 sp=0xc420051d10 pc=0x10ed688
testing.(*M).Run(0xc420051f18, 0x12474b6)
/Users/hiro/go/src/testing/testing.go:932 +0x111 fp=0xc420051ec0 sp=0xc420051dc8 pc=0x10ec031
runtime_test.TestMain(0xc420051f18)
/Users/hiro/go/src/runtime/crash_test.go:28 +0x2f fp=0xc420051f10 sp=0xc420051ec0 pc=0x1216c9f
main.main()
runtime/_test/_testmain.go:902 +0xdb fp=0xc420051f80 sp=0xc420051f10 pc=0x126701b
runtime.main()
/Users/hiro/go/src/runtime/proc.go:185 +0x20d fp=0xc420051fe0 sp=0xc420051f80 pc=0x102f5dd
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420051fe8 sp=0xc420051fe0 pc=0x10612f1
goroutine 2 [force gc (idle)]:
runtime.gopark(0x131a290, 0x149a0c0, 0x130a49c, 0xf, 0x14, 0x1)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002c768 sp=0xc42002c738 pc=0x102fa7c
runtime.goparkunlock(0x149a0c0, 0x130a49c, 0xf, 0xc420000114, 0x1)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002c7a8 sp=0xc42002c768 pc=0x102fb6e
runtime.forcegchelper()
/Users/hiro/go/src/runtime/proc.go:235 +0xcc fp=0xc42002c7e0 sp=0xc42002c7a8 pc=0x102f89c
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002c7e8 sp=0xc42002c7e0 pc=0x10612f1
created by runtime.init.4
/Users/hiro/go/src/runtime/proc.go:224 +0x35
goroutine 3 [GC sweep wait]:
runtime.gopark(0x131a290, 0x149a3c0, 0x130941f, 0xd, 0x1021014, 0x1)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002cf60 sp=0xc42002cf30 pc=0x102fa7c
runtime.goparkunlock(0x149a3c0, 0x130941f, 0xd, 0x14, 0x1)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002cfa0 sp=0xc42002cf60 pc=0x102fb6e
runtime.bgsweep(0xc420020070)
/Users/hiro/go/src/runtime/mgcsweep.go:52 +0xa3 fp=0xc42002cfd8 sp=0xc42002cfa0 pc=0x10210d3
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002cfe0 sp=0xc42002cfd8 pc=0x10612f1
created by runtime.gcenable
/Users/hiro/go/src/runtime/mgc.go:216 +0x58
goroutine 4 [finalizer wait]:
runtime.gopark(0x131a290, 0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002d700 sp=0xc42002d6d0 pc=0x102fa7c
runtime.goparkunlock(0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002d740 sp=0xc42002d700 pc=0x102fb6e
runtime.runfinq()
/Users/hiro/go/src/runtime/mfinal.go:175 +0xb8 fp=0xc42002d7e0 sp=0xc42002d740 pc=0x1017ed8
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002d7e8 sp=0xc42002d7e0 pc=0x10612f1
created by runtime.createfing
/Users/hiro/go/src/runtime/mfinal.go:156 +0x62
goroutine 5 [syscall]:
runtime.notetsleepg(0x14ba2c0, 0xffffffffffffffff, 0x0)
/Users/hiro/go/src/runtime/lock_sema.go:280 +0x4b fp=0xc42002df80 sp=0xc42002df40 pc=0x10119eb
os/signal.signal_recv(0x0)
/Users/hiro/go/src/runtime/sigqueue.go:131 +0xa7 fp=0xc42002dfa8 sp=0xc42002df80 pc=0x1045807
os/signal.loop()
/Users/hiro/go/src/os/signal/signal_unix.go:22 +0x22 fp=0xc42002dfe0 sp=0xc42002dfa8 pc=0x10e4232
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002dfe8 sp=0xc42002dfe0 pc=0x10612f1
created by os/signal.init.0
/Users/hiro/go/src/os/signal/signal_unix.go:28 +0x41
goroutine 6 [select, locked to thread]:
runtime.gopark(0x131a2d8, 0x0, 0x1306abf, 0x6, 0x18, 0x1)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42003aca0 sp=0xc42003ac70 pc=0x102fa7c
runtime.selectgo(0xc42003af50, 0xc420076180)
/Users/hiro/go/src/runtime/select.go:395 +0x1138 fp=0xc42003af18 sp=0xc42003aca0 pc=0x103fff8
runtime.ensureSigM.func1()
/Users/hiro/go/src/runtime/signal_unix.go:511 +0x1fe fp=0xc42003afe0 sp=0xc42003af18 pc=0x105da9e
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42003afe8 sp=0xc42003afe0 pc=0x10612f1
created by runtime.ensureSigM
/Users/hiro/go/src/runtime/signal_unix.go:494 +0xda
goroutine 7 [chan receive]:
runtime.gopark(0x131a290, 0xc42005e358, 0x1308f6e, 0xc, 0xc420024117, 0x3)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002ee80 sp=0xc42002ee50 pc=0x102fa7c
runtime.goparkunlock(0xc42005e358, 0x1308f6e, 0xc, 0x17, 0x3)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002eec0 sp=0xc42002ee80 pc=0x102fb6e
runtime.chanrecv(0xc42005e300, 0x0, 0x1, 0x0)
/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002ef70 sp=0xc42002eec0 pc=0x1005dc4
runtime.chanrecv1(0xc42005e300, 0x0)
/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002efa0 sp=0xc42002ef70 pc=0x1005a6b
testing.(*M).before.func1(0xc42005e300)
/Users/hiro/go/src/testing/testing.go:1111 +0x38 fp=0xc42002efd8 sp=0xc42002efa0 pc=0x10efd98
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002efe0 sp=0xc42002efd8 pc=0x10612f1
created by testing.(*M).before
/Users/hiro/go/src/testing/testing.go:1110 +0x191
goroutine 8 [chan receive]:
runtime.gopark(0x131a290, 0xc420106058, 0x1308f6e, 0xc, 0xc42002f617, 0x3)
/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002f5e8 sp=0xc42002f5b8 pc=0x102fa7c
runtime.goparkunlock(0xc420106058, 0x1308f6e, 0xc, 0x1010f0120104017, 0x3)
/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002f628 sp=0xc42002f5e8 pc=0x102fb6e
runtime.chanrecv(0xc420106000, 0x0, 0xc42002f701, 0x1249879)
/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002f6d8 sp=0xc42002f628 pc=0x1005dc4
runtime.chanrecv1(0xc420106000, 0x0)
/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002f708 sp=0xc42002f6d8 pc=0x1005a6b
runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8)
/Users/hiro/go/src/runtime/rwmutex_test.go:103 +0x1eb fp=0xc42002f770 sp=0xc42002f708 pc=0x12498ab
runtime_test.TestRWMutex(0xc4200e20f0)
/Users/hiro/go/src/runtime/rwmutex_test.go:118 +0x12f fp=0xc42002f7a8 sp=0xc42002f770 pc=0x1249a0f
testing.tRunner(0xc4200e20f0, 0x131b2e0)
/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc42002f7d0 sp=0xc42002f7a8 pc=0x10eb8a0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002f7d8 sp=0xc42002f7d0 pc=0x10612f1
created by testing.(*T).Run
/Users/hiro/go/src/testing/testing.go:800 +0x314
goroutine 50 [running]:
goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1
goroutine 51 [running]:
goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
goroutine 52 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010efc0 sp=0xc42010efb8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010efc8 sp=0xc42010efc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
goroutine 53 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010f7c0 sp=0xc42010f7b8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010f7c8 sp=0xc42010f7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
goroutine 54 [running]:
goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
goroutine 55 [running]:
goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
goroutine 56 [runnable]:
runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:71 fp=0xc420110fc0 sp=0xc420110fb8 pc=0x1249540
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420110fc8 sp=0xc420110fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:97 +0x16d
goroutine 57 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4201117c0 sp=0xc4201117b8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201117c8 sp=0xc4201117c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9
goroutine 58 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc420111fc0 sp=0xc420111fb8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420111fc8 sp=0xc420111fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9
goroutine 59 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4200f47c0 sp=0xc4200f47b8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f47c8 sp=0xc4200f47c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9
goroutine 60 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010afc0 sp=0xc42010afb8 pc=0x12493c0
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010afc8 sp=0xc42010afc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9
goroutine 61 [runnable]:
runtime.(*RWMutex).RUnlock(0xc420104000)
/Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
/Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405
runtime.goexit()
/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010b7c8 sp=0xc42010b7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9
rax    0x4
rbx    0x3
rcx    0x700006055dc0
rdx    0x0
rdi    0x0
rsi    0x0
rbp    0x700006055dd0
rsp    0x700006055dc0
r8     0x700006055dc0
r9     0x8
r10    0x0
r11    0x246
r12    0x3b4a277fed96
r13    0xb03
r14    0x10326d0
r15    0x1602620
rip    0x10625b6
rflags 0x247
cs     0x7
fs     0x0
gs     0x0
*** Test killed with quit: ran too long (10m0s).
FAIL	runtime	600.024s
Does this issue reproduce with the latest release (go1.8.3)? System
details
go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/hiro/.go"
GORACE=""
GOROOT="/Users/hiro/go"
GOTOOLDIR="/Users/hiro/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/wq/dwn8hs0x7njbzty9f68y61700000gn/T/go-build091579411=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 darwin/amd64
GOROOT/bin/go tool compile -V: compile version devel +a89e6be5e4 Mon Jul 3 14:08:01 2017 +0000 X:framepointer
uname -v: Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.5
BuildVersion:	16F73
lldb --version: lldb-370.0.42
Swift-3.1
gdb --version: GNU gdb (GDB) 7.12.1
FWIW, sync.TestRWMutex doesn't fail.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/20903, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA84XUu1k0Ph9txpehaOl0Rr0D8KGks5sKtB6gaJpZM4ONvea
.

runtime.TestRWMutex was introduced few weeks ago.

80832974ac9306f992c797f8394e44d7f63f307e is a suspect.

Thanks for bisecting.
On Wed, Jul 5, 2017 at 10:46 AM, hirochachacha notifications@github.com
wrote:

8083297
https://github.com/golang/go/commit/80832974ac9306f992c797f8394e44d7f63f307e
is a suspect.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/20903#issuecomment-312971617, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_6Y8tEzPOdHgNjnAg8Q6vRjo6uzks5sKtzhgaJpZM4ONvea
.

@aclements, can you look at this?

@hirochachacha, thanks for the report. I haven't been able to reproduce this on either linux/amd64 or darwin/amd64 yet.
How many CPUs does your system have? From the traceback it looks like at least 5 (so I assume really 6 or 8).
Can you reproduce it with GOTRACEBACK=crash set and post the output?

How many CPUs does your system have? From the traceback it looks like at least 5 (so I assume really 6 or 8).

It's only 4.
$ sysctl hw | grep cpu
hw.ncpu: 4
hw.activecpu: 4
hw.cpufrequency_max: 1800000000
hw.cpufrequency_min: 1800000000
hw.cpufrequency: 1800000000
hw.cpufamily: 526772277
hw.cpu64bit_capable: 1
hw.cpusubtype: 4
hw.cputype: 7
hw.logicalcpu_max: 4
hw.logicalcpu: 4
hw.physicalcpu_max: 2
hw.physicalcpu: 2
hw.cputhreadtype: 1

Can you reproduce it with GOTRACEBACK=crash set and post the output?

$ GOTRACEBACK=crash go test -v runtime -run "TestRWMutex"
=== RUN   TestRWMutex
SIGQUIT: quit
PC=0x10625b6 m=2 sigcode=0

goroutine 0 [idle]:
runtime.usleep(0x8b00002710, 0x0, 0x68c779c709, 0x45d964b800, 0x271000000000, 0x8bb2880fa8, 0x45d964b800, 0x3, 0x0, 0x68c779c709, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:323 +0x36 fp=0x700005e8dde0 sp=0x700005e8ddc0 pc=0x10625b6
runtime.sysmon()
	/Users/hiro/go/src/runtime/proc.go:3799 +0xa8 fp=0x700005e8de68 sp=0x700005e8dde0 pc=0x1039a08
runtime.mstart1()
	/Users/hiro/go/src/runtime/proc.go:1172 +0x11e fp=0x700005e8de90 sp=0x700005e8de68 pc=0x103285e
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1142 +0x64 fp=0x700005e8dea8 sp=0x700005e8de90 pc=0x1032734

goroutine 1 [chan receive]:
runtime.gopark(0x131a290, 0xc420074418, 0x1308f6e, 0xc, 0xc420051b17, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc420051ac8 sp=0xc420051a98 pc=0x102fa7c
runtime.goparkunlock(0xc420074418, 0x1308f6e, 0xc, 0xc4200e8017, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc420051b08 sp=0xc420051ac8 pc=0x102fb6e
runtime.chanrecv(0xc4200743c0, 0x0, 0xc420051b01, 0x10ebc14)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc420051bb8 sp=0xc420051b08 pc=0x1005dc4
runtime.chanrecv1(0xc4200743c0, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc420051be8 sp=0xc420051bb8 pc=0x1005a6b
testing.(*T).Run(0xc4200e2000, 0x130879c, 0xb, 0x131b2e0, 0x108f201)
	/Users/hiro/go/src/testing/testing.go:801 +0x332 fp=0xc420051c98 sp=0xc420051be8 pc=0x10ebc32
testing.runTests.func1(0xc4200e2000)
	/Users/hiro/go/src/testing/testing.go:1053 +0x64 fp=0xc420051ce8 sp=0xc420051c98 pc=0x10efd04
testing.tRunner(0xc4200e2000, 0xc420051d98)
	/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc420051d10 sp=0xc420051ce8 pc=0x10eb8a0
testing.runTests(0xc42000c300, 0x1498000, 0xd7, 0xd7, 0x5f)
	/Users/hiro/go/src/testing/testing.go:1051 +0x2d8 fp=0xc420051dc8 sp=0xc420051d10 pc=0x10ed688
testing.(*M).Run(0xc420051f18, 0x12474b6)
	/Users/hiro/go/src/testing/testing.go:932 +0x111 fp=0xc420051ec0 sp=0xc420051dc8 pc=0x10ec031
runtime_test.TestMain(0xc420051f18)
	/Users/hiro/go/src/runtime/crash_test.go:28 +0x2f fp=0xc420051f10 sp=0xc420051ec0 pc=0x1216c9f
main.main()
	runtime/_test/_testmain.go:902 +0xdb fp=0xc420051f80 sp=0xc420051f10 pc=0x126701b
runtime.main()
	/Users/hiro/go/src/runtime/proc.go:185 +0x20d fp=0xc420051fe0 sp=0xc420051f80 pc=0x102f5dd
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420051fe8 sp=0xc420051fe0 pc=0x10612f1

goroutine 2 [force gc (idle)]:
runtime.gopark(0x131a290, 0x149a0c0, 0x130a49c, 0xf, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002c768 sp=0xc42002c738 pc=0x102fa7c
runtime.goparkunlock(0x149a0c0, 0x130a49c, 0xf, 0xc420000114, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002c7a8 sp=0xc42002c768 pc=0x102fb6e
runtime.forcegchelper()
	/Users/hiro/go/src/runtime/proc.go:235 +0xcc fp=0xc42002c7e0 sp=0xc42002c7a8 pc=0x102f89c
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002c7e8 sp=0xc42002c7e0 pc=0x10612f1
created by runtime.init.4
	/Users/hiro/go/src/runtime/proc.go:224 +0x35

goroutine 3 [GC sweep wait]:
runtime.gopark(0x131a290, 0x149a3c0, 0x130941f, 0xd, 0x1021014, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002cf60 sp=0xc42002cf30 pc=0x102fa7c
runtime.goparkunlock(0x149a3c0, 0x130941f, 0xd, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002cfa0 sp=0xc42002cf60 pc=0x102fb6e
runtime.bgsweep(0xc420020070)
	/Users/hiro/go/src/runtime/mgcsweep.go:52 +0xa3 fp=0xc42002cfd8 sp=0xc42002cfa0 pc=0x10210d3
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002cfe0 sp=0xc42002cfd8 pc=0x10612f1
created by runtime.gcenable
	/Users/hiro/go/src/runtime/mgc.go:216 +0x58

goroutine 4 [finalizer wait]:
runtime.gopark(0x131a290, 0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002d700 sp=0xc42002d6d0 pc=0x102fa7c
runtime.goparkunlock(0x14b9f10, 0x1309da5, 0xe, 0x14, 0x1)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002d740 sp=0xc42002d700 pc=0x102fb6e
runtime.runfinq()
	/Users/hiro/go/src/runtime/mfinal.go:175 +0xb8 fp=0xc42002d7e0 sp=0xc42002d740 pc=0x1017ed8
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002d7e8 sp=0xc42002d7e0 pc=0x10612f1
created by runtime.createfing
	/Users/hiro/go/src/runtime/mfinal.go:156 +0x62

goroutine 5 [syscall]:
runtime.notetsleepg(0x14ba2c0, 0xffffffffffffffff, 0x0)
	/Users/hiro/go/src/runtime/lock_sema.go:280 +0x4b fp=0xc42002df80 sp=0xc42002df40 pc=0x10119eb
os/signal.signal_recv(0x0)
	/Users/hiro/go/src/runtime/sigqueue.go:131 +0xa7 fp=0xc42002dfa8 sp=0xc42002df80 pc=0x1045807
os/signal.loop()
	/Users/hiro/go/src/os/signal/signal_unix.go:22 +0x22 fp=0xc42002dfe0 sp=0xc42002dfa8 pc=0x10e4232
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002dfe8 sp=0xc42002dfe0 pc=0x10612f1
created by os/signal.init.0
	/Users/hiro/go/src/os/signal/signal_unix.go:28 +0x41

goroutine 6 [select, locked to thread]:
runtime.gopark(0x131a2d8, 0x0, 0x1306abf, 0x6, 0x18, 0x1)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42003aca0 sp=0xc42003ac70 pc=0x102fa7c
runtime.selectgo(0xc42003af50, 0xc420074180)
	/Users/hiro/go/src/runtime/select.go:395 +0x1138 fp=0xc42003af18 sp=0xc42003aca0 pc=0x103fff8
runtime.ensureSigM.func1()
	/Users/hiro/go/src/runtime/signal_unix.go:511 +0x1fe fp=0xc42003afe0 sp=0xc42003af18 pc=0x105da9e
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42003afe8 sp=0xc42003afe0 pc=0x10612f1
created by runtime.ensureSigM
	/Users/hiro/go/src/runtime/signal_unix.go:494 +0xda

goroutine 7 [chan receive]:
runtime.gopark(0x131a290, 0xc42005e358, 0x1308f6e, 0xc, 0xc420024117, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002ee80 sp=0xc42002ee50 pc=0x102fa7c
runtime.goparkunlock(0xc42005e358, 0x1308f6e, 0xc, 0x17, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002eec0 sp=0xc42002ee80 pc=0x102fb6e
runtime.chanrecv(0xc42005e300, 0x0, 0x1, 0x0)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002ef70 sp=0xc42002eec0 pc=0x1005dc4
runtime.chanrecv1(0xc42005e300, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002efa0 sp=0xc42002ef70 pc=0x1005a6b
testing.(*M).before.func1(0xc42005e300)
	/Users/hiro/go/src/testing/testing.go:1111 +0x38 fp=0xc42002efd8 sp=0xc42002efa0 pc=0x10efd98
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002efe0 sp=0xc42002efd8 pc=0x10612f1
created by testing.(*M).before
	/Users/hiro/go/src/testing/testing.go:1110 +0x191

goroutine 8 [chan receive]:
runtime.gopark(0x131a290, 0xc420106058, 0x1308f6e, 0xc, 0xc42002f617, 0x3)
	/Users/hiro/go/src/runtime/proc.go:277 +0x12c fp=0xc42002f5e8 sp=0xc42002f5b8 pc=0x102fa7c
runtime.goparkunlock(0xc420106058, 0x1308f6e, 0xc, 0x1010f0120104017, 0x3)
	/Users/hiro/go/src/runtime/proc.go:283 +0x5e fp=0xc42002f628 sp=0xc42002f5e8 pc=0x102fb6e
runtime.chanrecv(0xc420106000, 0x0, 0xc42002f701, 0x1249879)
	/Users/hiro/go/src/runtime/chan.go:506 +0x304 fp=0xc42002f6d8 sp=0xc42002f628 pc=0x1005dc4
runtime.chanrecv1(0xc420106000, 0x0)
	/Users/hiro/go/src/runtime/chan.go:388 +0x2b fp=0xc42002f708 sp=0xc42002f6d8 pc=0x1005a6b
runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8)
	/Users/hiro/go/src/runtime/rwmutex_test.go:103 +0x1eb fp=0xc42002f770 sp=0xc42002f708 pc=0x12498ab
runtime_test.TestRWMutex(0xc4200e20f0)
	/Users/hiro/go/src/runtime/rwmutex_test.go:118 +0x12f fp=0xc42002f7a8 sp=0xc42002f770 pc=0x1249a0f
testing.tRunner(0xc4200e20f0, 0x131b2e0)
	/Users/hiro/go/src/testing/testing.go:754 +0xd0 fp=0xc42002f7d0 sp=0xc42002f7a8 pc=0x10eb8a0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42002f7d8 sp=0xc42002f7d0 pc=0x10612f1
created by testing.(*T).Run
	/Users/hiro/go/src/testing/testing.go:800 +0x314

goroutine 51 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 50 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1

goroutine 52 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010efc0 sp=0xc42010efb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010efc8 sp=0xc42010efc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 53 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010f7c0 sp=0xc42010f7b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010f7c8 sp=0xc42010f7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 54 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 55 [running]:
	goroutine running on other thread; stack unavailable
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105

goroutine 56 [runnable]:
runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:71 fp=0xc420110fc0 sp=0xc420110fb8 pc=0x1249540
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420110fc8 sp=0xc420110fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:97 +0x16d

goroutine 57 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4201117c0 sp=0xc4201117b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201117c8 sp=0xc4201117c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 58 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc420111fc0 sp=0xc420111fb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420111fc8 sp=0xc420111fc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 59 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc4200f47c0 sp=0xc4200f47b8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f47c8 sp=0xc4200f47c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 60 [runnable]:
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:56 fp=0xc42010afc0 sp=0xc42010afb8 pc=0x12493c0
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010afc8 sp=0xc42010afc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

goroutine 61 [runnable]:
runtime.(*RWMutex).RUnlock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010b7c8 sp=0xc42010b7c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:99 +0x1b9

rax    0x4
rbx    0x3
rcx    0x700005e8ddc0
rdx    0x0
rdi    0x0
rsi    0x0
rbp    0x700005e8ddd0
rsp    0x700005e8ddc0
r8     0x700005e8ddc0
r9     0x16
r10    0x0
r11    0x246
r12    0x746f44e68d77
r13    0xb03
r14    0x10326d0
r15    0x1602620
rip    0x10625b6
rflags 0x247
cs     0x7
fs     0x0
gs     0x0

-----

SIGQUIT: quit
PC=0x10626db m=3 sigcode=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0xc400001403, 0x103adeb, 0xc420023300, 0x149a001, 0x700005f10e38, 0xc420000d80, 0x700005f10e50, 0x105c6b3, 0xffffffffffffffff, 0x1036752, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:445 +0xb fp=0x700005f10df8 sp=0x700005f10df0 pc=0x10626db
runtime.semasleep1(0xffffffffffffffff, 0x1036752)
	/Users/hiro/go/src/runtime/os_darwin.go:413 +0x52 fp=0x700005f10e38 sp=0x700005f10df8 pc=0x102bc52
runtime.semasleep.func1()
	/Users/hiro/go/src/runtime/os_darwin.go:432 +0x33 fp=0x700005f10e60 sp=0x700005f10e38 pc=0x105c6b3
runtime.systemstack(0xc420023300)
	/Users/hiro/go/src/runtime/asm_amd64.s:344 +0x79 fp=0x700005f10e68 sp=0x700005f10e60 pc=0x105e769
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1125 fp=0x700005f10e70 sp=0x700005f10e68 pc=0x10326d0
rax    0xe
rbx    0x700005f10e60
rcx    0x700005f10df0
rdx    0xc42002dee8
rdi    0x1403
rsi    0x105e6e0
rbp    0x700005f10e28
rsp    0x700005f10df0
r8     0xc420001500
r9     0xc420000d80
r10    0x0
r11    0x286
r12    0x0
r13    0xf1
r14    0x11
r15    0x0
rip    0x10626db
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

-----

SIGQUIT: quit
PC=0x10626db m=4 sigcode=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0x700000001103, 0x0, 0xc420068110, 0x1, 0xc420025900, 0xc420001200, 0x700005f93db0, 0x105c6b3, 0xffffffffffffffff, 0x0, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:445 +0xb fp=0x700005f93d58 sp=0x700005f93d50 pc=0x10626db
runtime.semasleep1(0xffffffffffffffff, 0x0)
	/Users/hiro/go/src/runtime/os_darwin.go:413 +0x52 fp=0x700005f93d98 sp=0x700005f93d58 pc=0x102bc52
runtime.semasleep.func1()
	/Users/hiro/go/src/runtime/os_darwin.go:432 +0x33 fp=0x700005f93dc0 sp=0x700005f93d98 pc=0x105c6b3
runtime.systemstack(0x700005f93dd8)
	/Users/hiro/go/src/runtime/asm_amd64.s:360 +0xab fp=0x700005f93dc8 sp=0x700005f93dc0 pc=0x105e79b
runtime.semasleep(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:431 +0x44 fp=0x700005f93e00 sp=0x700005f93dc8 pc=0x102bd84
runtime.notesleep(0xc420030b90)
	/Users/hiro/go/src/runtime/lock_sema.go:167 +0xe9 fp=0x700005f93e38 sp=0x700005f93e00 pc=0x1011609
runtime.(*rwmutex).lock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:89 +0x5c fp=0x700005f93e60 sp=0x700005f93e38 pc=0x105d71c
runtime.systemstack(0xc420022000)
	/Users/hiro/go/src/runtime/asm_amd64.s:344 +0x79 fp=0x700005f93e68 sp=0x700005f93e60 pc=0x105e769
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1125 fp=0x700005f93e70 sp=0x700005f93e68 pc=0x10326d0
goroutine 50 [running]:
runtime.systemstack_switch()
	/Users/hiro/go/src/runtime/asm_amd64.s:298 fp=0xc4200f56f0 sp=0xc4200f56e8 pc=0x105e6e0
runtime.(*rwmutex).lock(0xc420104000)
	/Users/hiro/go/src/runtime/rwmutex.go:86 +0xc3 fp=0xc4200f5730 sp=0xc4200f56f0 pc=0x103e623
runtime.(*RWMutex).Lock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:366 +0x2d fp=0xc4200f5748 sp=0xc4200f5730 pc=0x105a9ed
runtime_test.writer(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:73 +0x6d fp=0xc4200f57c0 sp=0xc4200f5748 pc=0x12495ad
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f57c8 sp=0xc4200f57c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:92 +0xc1
rax    0xe
rbx    0xc420030a80
rcx    0x700005f93d50
rdx    0x700005f93dd8
rdi    0x1103
rsi    0x105e601
rbp    0x700005f93d88
rsp    0x700005f93d50
r8     0xc42006a480
r9     0x15
r10    0x0
r11    0x286
r12    0xc420100038
r13    0xf1
r14    0x11
r15    0x0
rip    0x10626db
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

-----

SIGQUIT: quit
PC=0x10626db m=5 sigcode=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0xc400001603, 0x700000000000, 0x10339a1, 0xc4200c6110, 0x1, 0xc42006a180, 0x700006016da8, 0x105c6b3, 0xffffffffffffffff, 0xc400000000, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:445 +0xb fp=0x700006016d50 sp=0x700006016d48 pc=0x10626db
runtime.semasleep1(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:413 +0x52 fp=0x700006016d90 sp=0x700006016d50 pc=0x102bc52
runtime.semasleep.func1()
	/Users/hiro/go/src/runtime/os_darwin.go:432 +0x33 fp=0x700006016db8 sp=0x700006016d90 pc=0x105c6b3
runtime.systemstack(0x700006016dd0)
	/Users/hiro/go/src/runtime/asm_amd64.s:360 +0xab fp=0x700006016dc0 sp=0x700006016db8 pc=0x105e79b
runtime.semasleep(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:431 +0x44 fp=0x700006016df8 sp=0x700006016dc0 pc=0x102bd84
runtime.notesleep(0xc420068110)
	/Users/hiro/go/src/runtime/lock_sema.go:167 +0xe9 fp=0x700006016e30 sp=0x700006016df8 pc=0x1011609
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x700006016e60 sp=0x700006016e30 pc=0x105d696
runtime.systemstack(0xc420024600)
	/Users/hiro/go/src/runtime/asm_amd64.s:344 +0x79 fp=0x700006016e68 sp=0x700006016e60 pc=0x105e769
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1125 fp=0x700006016e70 sp=0x700006016e68 pc=0x10326d0
goroutine 51 [running]:
runtime.systemstack_switch()
	/Users/hiro/go/src/runtime/asm_amd64.s:298 fp=0xc4200f9708 sp=0xc4200f9700 pc=0x105e6e0
runtime.(*rwmutex).rlock(0xc420104000)
	/Users/hiro/go/src/runtime/rwmutex.go:36 +0x5b fp=0xc4200f9730 sp=0xc4200f9708 pc=0x103e48b
runtime.(*RWMutex).RLock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:358 +0x2d fp=0xc4200f9748 sp=0xc4200f9730 pc=0x105a96d
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:58 +0x6d fp=0xc4200f97c0 sp=0xc4200f9748 pc=0x124942d
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4200f97c8 sp=0xc4200f97c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
rax    0xe
rbx    0xc420068000
rcx    0x700006016d48
rdx    0x700006016dd0
rdi    0x1603
rsi    0x105e601
rbp    0x700006016d80
rsp    0x700006016d48
r8     0xc4200c9080
r9     0xc42006a180
r10    0x0
r11    0x286
r12    0xc420100038
r13    0xf1
r14    0x11
r15    0x0
rip    0x10626db
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

-----

SIGQUIT: quit
PC=0x10626db m=6 sigcode=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0xc400001903, 0x0, 0xc420108300, 0x100700006099d88, 0x3, 0xc4200c8180, 0x700006099da8, 0x105c6b3, 0xffffffffffffffff, 0xc400000000, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:445 +0xb fp=0x700006099d50 sp=0x700006099d48 pc=0x10626db
runtime.semasleep1(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:413 +0x52 fp=0x700006099d90 sp=0x700006099d50 pc=0x102bc52
runtime.semasleep.func1()
	/Users/hiro/go/src/runtime/os_darwin.go:432 +0x33 fp=0x700006099db8 sp=0x700006099d90 pc=0x105c6b3
runtime.systemstack(0x700006099dd0)
	/Users/hiro/go/src/runtime/asm_amd64.s:360 +0xab fp=0x700006099dc0 sp=0x700006099db8 pc=0x105e79b
runtime.semasleep(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:431 +0x44 fp=0x700006099df8 sp=0x700006099dc0 pc=0x102bd84
runtime.notesleep(0xc4200c6110)
	/Users/hiro/go/src/runtime/lock_sema.go:167 +0xe9 fp=0x700006099e30 sp=0x700006099df8 pc=0x1011609
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x700006099e60 sp=0x700006099e30 pc=0x105d696
runtime.systemstack(0xc420023300)
	/Users/hiro/go/src/runtime/asm_amd64.s:344 +0x79 fp=0x700006099e68 sp=0x700006099e60 pc=0x105e769
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1125 fp=0x700006099e70 sp=0x700006099e68 pc=0x10326d0
goroutine 54 [running]:
runtime.systemstack_switch()
	/Users/hiro/go/src/runtime/asm_amd64.s:298 fp=0xc42010ff08 sp=0xc42010ff00 pc=0x105e6e0
runtime.(*rwmutex).rlock(0xc420104000)
	/Users/hiro/go/src/runtime/rwmutex.go:36 +0x5b fp=0xc42010ff30 sp=0xc42010ff08 pc=0x103e48b
runtime.(*RWMutex).RLock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:358 +0x2d fp=0xc42010ff48 sp=0xc42010ff30 pc=0x105a96d
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:58 +0x6d fp=0xc42010ffc0 sp=0xc42010ff48 pc=0x124942d
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc42010ffc8 sp=0xc42010ffc0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
rax    0xe
rbx    0xc4200c6000
rcx    0x700006099d48
rdx    0x700006099dd0
rdi    0x1903
rsi    0x105e601
rbp    0x700006099d80
rsp    0x700006099d48
r8     0xc420108300
r9     0x6
r10    0xc420100040
r11    0x286
r12    0xc420100038
r13    0xf1
r14    0x11
r15    0x0
rip    0x10626db
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

-----

SIGQUIT: quit
PC=0x10626db m=7 sigcode=0

goroutine 0 [idle]:
runtime.mach_semaphore_wait(0x1c03, 0x0, 0x70000611cd78, 0xfffffffffffffade, 0xc420001c80, 0xc420001c80, 0x70000611cda8, 0x105c6b3, 0xffffffffffffffff, 0xc400000000, ...)
	/Users/hiro/go/src/runtime/sys_darwin_amd64.s:445 +0xb fp=0x70000611cd50 sp=0x70000611cd48 pc=0x10626db
runtime.semasleep1(0xffffffffffffffff, 0xc400000000)
	/Users/hiro/go/src/runtime/os_darwin.go:413 +0x52 fp=0x70000611cd90 sp=0x70000611cd50 pc=0x102bc52
runtime.semasleep.func1()
	/Users/hiro/go/src/runtime/os_darwin.go:432 +0x33 fp=0x70000611cdb8 sp=0x70000611cd90 pc=0x105c6b3
runtime.systemstack(0x70000611cdd0)
	/Users/hiro/go/src/runtime/asm_amd64.s:360 +0xab fp=0x70000611cdc0 sp=0x70000611cdb8 pc=0x105e79b
runtime.semasleep(0xffffffffffffffff, 0x700000000000)
	/Users/hiro/go/src/runtime/os_darwin.go:431 +0x44 fp=0x70000611cdf8 sp=0x70000611cdc0 pc=0x102bd84
runtime.notesleep(0xc420031d10)
	/Users/hiro/go/src/runtime/lock_sema.go:167 +0xe9 fp=0x70000611ce30 sp=0x70000611cdf8 pc=0x1011609
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x70000611ce60 sp=0x70000611ce30 pc=0x105d696
runtime.systemstack(0xc420001cb8)
	/Users/hiro/go/src/runtime/asm_amd64.s:344 +0x79 fp=0x70000611ce68 sp=0x70000611ce60 pc=0x105e769
runtime.mstart()
	/Users/hiro/go/src/runtime/proc.go:1125 fp=0x70000611ce70 sp=0x70000611ce68 pc=0x10326d0
goroutine 55 [running]:
runtime.systemstack_switch()
	/Users/hiro/go/src/runtime/asm_amd64.s:298 fp=0xc420110708 sp=0xc420110700 pc=0x105e6e0
runtime.(*rwmutex).rlock(0xc420104000)
	/Users/hiro/go/src/runtime/rwmutex.go:36 +0x5b fp=0xc420110730 sp=0xc420110708 pc=0x103e48b
runtime.(*RWMutex).RLock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:358 +0x2d fp=0xc420110748 sp=0xc420110730 pc=0x105a96d
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:58 +0x6d fp=0xc4201107c0 sp=0xc420110748 pc=0x124942d
runtime.goexit()
	/Users/hiro/go/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc4201107c8 sp=0xc4201107c0 pc=0x10612f1
created by runtime_test.HammerRWMutex
	/Users/hiro/go/src/runtime/rwmutex_test.go:95 +0x105
rax    0xe
rbx    0xc420031c00
rcx    0x70000611cd48
rdx    0x70000611cdd0
rdi    0x1c03
rsi    0x105e601
rbp    0x70000611cd80
rsp    0x70000611cd48
r8     0xc420108480
r9     0xc420001a08
r10    0xc420106040
r11    0x286
r12    0xc420106038
r13    0xf1
r14    0x11
r15    0x0
rip    0x10626db
rflags 0x286
cs     0x7
fs     0x0
gs     0x0

-----

*** Test killed: ran too long (10m0s).
FAIL	runtime	605.013s

Thank you.

It's only 4.

Oh, the test adjusts GOMAXPROCS itself. Sorry, should have thought of that.

Can you reproduce it with GOTRACEBACK=crash set and post the output?

goroutine 8 [chan receive]:
runtime_test.HammerRWMutex(0x4, 0xa, 0x3e8)

GOMAXPROCS=4, numReaders=10, n=1000
goroutine 52 [runnable]:
goroutine 53 [runnable]:
goroutine 57 [runnable]:
goroutine 58 [runnable]:
goroutine 59 [runnable]:
goroutine 60 [runnable]:

Readers that haven't been scheduled yet.
goroutine 56 [runnable]:

Writer that hasn't been scheduled yet.
goroutine 61 [runnable]:
runtime.(*RWMutex).RUnlock(0xc420104000)
	/Users/hiro/go/src/runtime/export_test.go:361 +0x3c fp=0xc42010b748 sp=0xc42010b740 pc=0x105a9bc
runtime_test.reader(0xc420104000, 0x3e8, 0xc420102000, 0xc420106000)
	/Users/hiro/go/src/runtime/rwmutex_test.go:66 +0x45 fp=0xc42010b7c0 sp=0xc42010b748 pc=0x1249405

This goroutine holds a read lock and was about to release it but got descheduled. This is probably the bug.
PC=0x10626db m=4 sigcode=0
runtime.(*rwmutex).lock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:89 +0x5c fp=0x700005f93e60 sp=0x700005f93e38 pc=0x105d71c
goroutine 50 [running]:

Pending writer, waiting to be woken by the last reader.
PC=0x10626db m=5 sigcode=0
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x700006016e60 sp=0x700006016e30 pc=0x105d696
goroutine 51 [running]:

Pending reader, on queue waiting to be woken after the writer releases.
PC=0x10626db m=6 sigcode=0
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x700006099e60 sp=0x700006099e30 pc=0x105d696
goroutine 54 [running]:

Same.
PC=0x10626db m=7 sigcode=0
runtime.(*rwmutex).rlock.func1()
	/Users/hiro/go/src/runtime/rwmutex.go:49 +0xa6 fp=0x70000611ce60 sp=0x70000611ce30 pc=0x105d696
goroutine 55 [running]:

Same.
So, the lock is in read mode, held by only goroutine 61. There's a pending writer and a few pending readers behind the writer. But goroutine 61 got descheduled, and meanwhile four other goroutines got scheduled and blocked their Ms and Ps attempting to acquire the lock. That consumed all of GOMAXPROCS, so goroutine 61 can't run and release its read lock, leading to deadlock.
Sounds like the read lock either needs to disallow rescheduling, or we need to release the P while blocking the M.

I can now reproduce this easily by adding a Gosched in the middle of the reader loop.
Dropping the P is really messy since that requires using lockOSThread and notetsleepg, which winds up in stoplockedm, which itself uses m.park, causing things to go haywire when we try to wake a pending reader.
Disallowing rescheduling is less messy, though TestParallelRWMutexReaders is going to need some rewriting since it depends on potentially blocking channel sends.

Thank you for the fix, it works fine.
Also thank you for writing up the description, I'm glad to see that.

Thank you for reporting the issue. :)

authors: aclements bradfitz davecheney hirochachacha


text:
runtime, cmd/ld: darwin/arm and darwin/arm64 build failing, darwin/amd64 occasionally hangs

https://golang.org/cl/108679 seems to have broken the darwin/arm and darwin/arm64 builds.
Also, I am now experiencing occasional hangs during make.bash. Sample SIGQUIT output:
$ ./make.bash
Building Go cmd/dist using /Users/josh/go/1.4.
Building Go toolchain1 using /Users/josh/go/1.4.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for darwin/amd64.
# testing/iotest
SIGQUIT: quit
PC=0x1057115 m=1 sigcode=0

goroutine 0 [idle]:
runtime.usleep(0x5700002710, 0x0, 0x45d9ff8c62, 0x45d964b800, 0x271000000000, 0x576c68ca9e, 0x45d964b800, 0x2, 0x0, 0x45d9ff8c62, ...)
	/Users/josh/go/tip/src/runtime/sys_darwin_amd64.s:418 +0x45
runtime.sysmon()
	/Users/josh/go/tip/src/runtime/proc.go:4256 +0xd0
runtime.mstart1()
	/Users/josh/go/tip/src/runtime/proc.go:1229 +0xe6
runtime.mstart()
	/Users/josh/go/tip/src/runtime/proc.go:1195 +0x6e

goroutine 1 [runnable, locked to thread]:
runtime.gopark(0x183bec0, 0xc000066058, 0x1820255, 0xc, 0xc000020e17, 0x3)
	/Users/josh/go/tip/src/runtime/proc.go:291 +0x105
runtime.goparkunlock(0xc000066058, 0x1820255, 0xc, 0x17, 0x3)
	/Users/josh/go/tip/src/runtime/proc.go:297 +0x5e
runtime.chanrecv(0xc000066000, 0x0, 0xc000000101, 0x10167c8)
	/Users/josh/go/tip/src/runtime/chan.go:520 +0x2d1
runtime.chanrecv1(0xc000066000, 0x0)
	/Users/josh/go/tip/src/runtime/chan.go:402 +0x2b
runtime.gcenable()
	/Users/josh/go/tip/src/runtime/mgc.go:217 +0x6f
runtime.main()
	/Users/josh/go/tip/src/runtime/proc.go:161 +0x119
runtime.goexit()
	/Users/josh/go/tip/src/runtime/asm_amd64.s:1356 +0x1

rax    0x4
rbx    0x2
rcx    0xc000051e00
rdx    0x0
rdi    0x0
rsi    0x0
rbp    0xc000051e10
rsp    0xc000051e00
r8     0xc000051e00
r9     0x0
r10    0x0
r11    0x206
r12    0x85f8e928f07
r13    0x0
r14    0xb0000000
r15    0x0
rip    0x1057115
rflags 0x207
cs     0x7
fs     0x0
gs     0x0
go tool dist: FAILED: /Users/josh/go/tip/pkg/tool/darwin_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2

cc @randall77

I suspect this darwin/amd64 failure from the dashboard is the same thing: https://build.golang.org/log/16b7534fc8d85a751999df12ffb24f7eb825e79a

CL 110123 already out for the arm64 fix.

I haven’t experienced it in a while. Closing until proven otherwise.


text:
x/vgo: Doesn't seem to be finding tags correctly

What version of Go are you using (go version)?
go version go1.10.2 linux/amd64 vgo:2018-02-20.1
Does this issue reproduce with the latest release?
Yes (of vgo, haven't updated Go if there's a new release of that).
What operating system and processor architecture are you using (go env)?
Linux amd64.
What did you do?
Tried several different ways to use v3.0.0-rc5 of my library: https://github.com/volatiletech/sqlboiler/tree/v3.0.0-rc5.
I imported:
package main // import "github.com/aarondl/newproject"

import (
	"fmt"
	"os"

	"github.com/volatiletech/sqlboiler/v3/strmangle"
)

func main() {
	_ = strmangle.TitleCase
}

And then used a go.mod that specified v3.0.0-rc5.
I also tried to list the tags available in that repo:
$ vgo list -t github.com/volatiletech/sqlboiler
github.com/volatiletech/sqlboiler
	v1.0.0

What did you expect to see?
I expected to see the tag v3.0.0-rc5 in the go.mod file (and I expected it to stay when I manually coerced it to the correct thing).
I expected to see it correctly list the v1, v2, and v3 tags that exist in that repository, here's some of the tags
that I expected to see:
v1.0.0
v2.0.0
v2.7.1
v2.7.2
v3.0.0-rc4
v3.0.0-rc5

What did you see instead?
I do not see a tag (though I do see the correct commit) in the vgo go.mod file:
module github.com/aarondl/newproject

require (
	github.com/volatiletech/sqlboiler v0.0.0-20180620223943-64005efb0df2
)

I do not see the correct tags listed in the repository:
vgo list -t github.com/volatiletech/sqlboiler
github.com/volatiletech/sqlboiler
	v1.0.0

sqlboiler needs a go.mod file spevifiying a v3 module path. Add that and you should be golden.

go will not use any v2 or later tag in a source code repository without first checking that it has a go.mod with a module path declaration ending in that major version (for example, module "my/thing/v2"). Vgo uses that declaration as evidence that the author is using semantic import versioning to name packages within that module. This is especially important for multi-package modules, since the import paths within the module must contain the /v2/ element to avoid referring back to the v1 module.

Ugh. I guess I didn't read close enough. Answered my own question I suppose. The reasoning is unfortunately kind of sound too so I can't even nitpick it too much. Though I think it's definitely a very bad decision to have done it this way. How am I supposed to support non-vgo at the same time? If I change all these import paths to use /v3, it'll break my existing users that don't use vgo since that isn't an import path that can ever possibly exist.

There are point releases for 1.10 and 1.9 that allow working with vX paths. For the this transition, some packages will need to continue to use the v0-rev notation to get versions larger then v1. What you discovered has already been addressed.

authors: aarondl kardianos


text:
cmd/go: 'go mod tidy' does not add indirect private dependencies

What version of Go are you using (go version)?
go version go1.11.1 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/karysto/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/karysto/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build201986556=/tmp/go-build -gno-record-gcc-switches"
What did you do?
I have a private repo I'm working on called parent_repo, it imports another private repo I wrote called child_repo. child_repo imports another private repo I wrote called grandchild_repo. All of these repos have go.mod files. In this case, grandchild_repo is an indirect dependency of parent_repo.
When I run go mod tidy on parent_repo, child_repo appears, but grandchild_repo does not. After adding grandchild_repo manually to parent_repo's mod file (with an associated replace directive to find it locally), go mod vendor and go build -mod=vendor works perfectly, the build succeeds. The problem is that if I do go mod tidy on parent_repo, my manually added grandchild_repo entry is removed, and my builds fail.
My use case is wanting to automate gathering dependencies to vendor before running  a CI pipeline, but I can't right now because of this issue.
What did you expect to see?
I expected to see go mod tidy add my indirect dependency to go.mod (so that I didn't have to add it manually) and the build to succeed as a result.
What did you see instead?
I see go.mod tidy remove the grandchild dependency and the build failing

@bcmills
@gopherbot needsinvestigation modules

@karysto taking your example; given child_repo is a module, then its dependencies (including grandchild_repo) will not appear in parent_repo. The dependency relationship still exists: go list -m all will show you all your dependencies in case you need to see that list.
This is working as intended.

@myitcv thanks for taking a look. If the required dependencies (in this case grandchild_repo) aren't in go.mod, then go build fails. Is there a workflow or tool I'm missing that automates adding these sub-dependencies to go.mod to allow the build to succeed?

@karysto sorry for just a quick comment, but does it seem like #26241 might be related?
Also, would you be able to put together 3 or so short but representative go.mod files that capture the essence of what you are seeing?
(A full blown repository on github that shows what you are seeing would be even better, but maybe to start some sample go.mod files could help make the nature of the problem more concrete).

@karysto

Do you have an idea of what other possible issue this could be related to that I might be missing?

Not without a repro, no.

authors: andybons karysto myitcv thepudds


text:
cmd/go: go get fails for long paths

tl;dr

Having dependencies behind an auth scheme is not possible and/or workarounds are not practical/usable for developers and build pipelines.
Go toolchain does not understand urls with more than two path items

Background
I have a private/hidden project hosted on GitLab where the URL looks something like this:
gitlab.com/my-company/my-project/my-subproject/my-important-library
Since it's a private repository, there's a need to authenticate. The simplest way is to use SSH with a key pair, as it avoids user interaction. However the go toolchain insists on using HTTPS, possibly due to the way gitlab handles go-get=1 requests. The docs suggest two approaches to get around this:

HTTPS: authenticate using credentials from .netrc
Force SSH: rewrite url to trick git into using ssh instead of https

None of these workarounds seems to work. Aside from that, there are some problems:
Using .netrc uses clear text passwords/tokens and it's not possible to use several credentials per host. Using .gitconfig globally does not allow several credentials per host. Configuring it locally for each project is a possibility. All of these approaches get sort of hidden away and are not very intuitive for anyone who needs to use my-important-library. It's also a nightmare to setup a build server.
Having lost the ssh fight with git/go get/go mod I tried adding GIT_TERMINAL_PROMPT=1 to my commands like so:
GIT_TERMINAL_PROMPT=1 go get gitlab.com/my-company/my-project/my-subproject/my-important-library
GIT_TERMINAL_PROMPT=1 go mod download
This introduced me to a different problem. Seems like go can only understand urls in the form <host>/<user>/<library>.
What did you do?
$ GIT_TERMINAL_PROMPT=1 go get gitlab.com/my-company/my-project/my-subproject/my-important-library

What did you expect to see?
EXIT_CODE=0 and my-important-library on disk
What did you see instead?
$ GIT_TERMINAL_PROMPT=1 go get gitlab.com/my-company/my-project/my-subproject/my-important-library
Username for 'https://gitlab.com': palsivertsen
Password for 'https://palsivertsen@gitlab.com':
# cd .; git clone https://gitlab.com/my-company/my-project.git /home/pal/projects/go/src/gitlab.com/my-company/my-project
Cloning into '/home/pal/projects/go/src/gitlab.com/my-company/my-project'...
remote: The project you were looking for could not be found.
fatal: repository 'https://gitlab.com/my-company/my-project.git/' not found
package gitlab.com/my-company/my-project/my-subproject/my-important-library: exit status 128

Note that the half the url (/my-subproject/my-important-library) is missing.
System details
go version go1.12 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/pal/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/pal/projects/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.12 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.12
uname -sr: Linux 4.15.0-45-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.6 LTS
Release:	16.04
Codename:	xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.23-0ubuntu11) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1

$ git version
git version 2.7.4

From Jan Mercl at https://groups.google.com/forum/?pli=1#!topic/golang-nuts/83hUVBGu7rA :
Seems like your git repo is just misconfigured.  go get does not actually download things, it calls out git or other VCS to do that. I'm also using gitlab for private repositories and have no issues with go get.
Example https (wrong) config:
==== jnml@4670:~/src/modernc.org/ql> cat .git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = https://gitlab.com/cznic/ql
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
==== jnml@4670:~/src/modernc.org/ql>

Make sure the url item has the right (git) protocol. Example correct config:
==== jnml@4670:~/src/modernc.org/cc> cat .git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = git@gitlab.com:cznic/cc
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master
[branch "gccgo"]
	remote = origin
	merge = refs/heads/gccgo
[branch "feb"]
	remote = origin
	merge = refs/heads/feb
==== jnml@4670:~/src/modernc.org/cc>

Above assumes you have your keys correctly registered at gitlab.

Seems like your git repo is just misconfigured.

It looks like you're referring to git remote configuration. I don't think that affects how go get will fetch dependencies?
The workaround
I've been able to get it working, but it's very unintuitive and will force all developers to use ssh transport.
My goal is to fetch a go module over ssh located at gitlab.com/my-company/my-project/my-subproject/my-important-library
The first thing I needed to do was to rename the go module from gitlab.com/my-company/my-project/my-subproject/my-important-library to gitlab.com/my-company/my-project/my-subproject/my-important-library.git (add .git ending).
Then I updated my global .gitconfig to rewrite all gitlab requests over HTTPS like so:
git config --global url."git@gitlab.com:".insteadOf https://gitlab.com/

Lastly I added .git postfix to all my import paths:
import (
  "gitlab.com/my-company/my-project/my-subproject/my-important-library.git"
  "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/foo"
  "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/bar"
)

Problems

The name of the module needs to change (.git postfix in go.mod). This breaks all existing usage of the module.
Changing the global git config in this way might cause unexpected behaviour later on.
This gitconfig, or .netrc equivalent, hack needs to be done on every machine that deals with code that uses this dependency (developers, build systems, etc).
The import path changes, even though the actual location does not.
Importing alongside public libraries with similar path looks weird:

import (
  "gitlab.com/my-company/my-project/my-subproject/my-important-library.git/foo"
  "gitlab.com/my-company/my-project/my-subproject/my-public-library/foo" // <- No ".git" postfix!
)

Solutions
#30304 proposes some solutions to this problem (Idea 1 (add a query param for selecting a transport) and Idea 2 (let the server return multiple go-import URLs)), but I don't think depending on changes to server implementations is the way to go here.
Proposal 1 - Make go tool chain smarter in how it selects transport for downloading dependencies
Automatically try ssh if git clone(?) fails over https fails. The working protocol could be cached for future requests.
Proposal 2 - Override dependency transport for the go tool chain
Introduce a way to override the transport used for different dependencies.
Example: Tool chain looks for a file named go.transport (similar to go.mod):
ssh (
  gitlab.com/my-company/my-project/my-subproject/my-important-library
)

If this file is outside the project path or not in VCS, then each developer can override this however they like.
It is important that this is configured in the go tool chain and not in git, so that we don't mess up the git tool itself.

Proposal 1 - Make go tool chain smarter in how it selects transport for downloading dependencies

That is exactly #30304, which you've already found. (Note the resolution in https://github.com/golang/go/issues/30304#issuecomment-470597610.)

Proposal 2 - Override dependency transport for the go tool chain

That should not be necessary once #29888 is addressed.

To address some specific points:

My goal is to fetch a go module over ssh located at gitlab.com/my-company/my-project/my-subproject/my-important-library

Why force ssh instead of fixing HTTPS?

Changing the global git config [to use https instead of ssh] might cause unexpected behaviour later on.

Any change to the go command might cause unexpected behavior. If there is a specific reason for concern with regard to git and insteadOf, please elaborate.

This gitconfig, or .netrc equivalent, hack needs to be done on every machine that deals with code that uses this dependency (developers, build systems, etc).

Don't you need to configure every machine that needs access to a private repo with credentials anyway?

That is exactly #30304, which you've already found. (Note the resolution in #30304 (comment).)

No, in #30304 both proposals rely on the server to tell go which transport to use. Proposal 1 is a fallback solution and does not rely on the server to select a protocol.

Why force ssh instead of fixing HTTPS?

See 26232 comment

If there is a specific reason for concern with regard to git and insteadOf, please elaborate.

I'm not sure if this will be an issue, but if one configure git with  url."git@gitlab.com:".insteadOf https://gitlab.com/ it will affect the whole domain.

Don't you need to configure every machine that needs access to a private repo with credentials anyway?

Yes, I guess you're right.

It just feels wrong to setup (in my case) additional credentials for go when git is happy to work with the credentials already in place.

I think the rationale in https://github.com/golang/go/issues/30304#issuecomment-470597610 still applies here.

Why force ssh instead of fixing HTTPS?

See 26232 comment

In that comment, you state:

Making HTTP calls that requires authentication is (IMO) a poor choice compared to SSH because it requires either user interaction (2FA) or weak credentials (compared to SSH). Another argument to drop HTTP is that SSH credentials are in most cases only authorized for GIT, but HTTP credentials in some cases gives access to a wider API.

I don't see why either of those is intrinsically the case. GitHub “personal access tokens” can be authorized for repo access only. SSH keys either require a password (that is, a user interaction similar to that required by 2FA), or provide a level of security similar to a passwordless SSH key (if someone has access to your machine's SSH private key, that's just as bad as someone who has access to your machine's HTTPS access token).
Given that the practical difference is very slight, it doesn't seem worthwhile to add extra complexity to the go command or its protocols to address.

authors: bcmills ianlancetaylor palsivertsen


text:
os: windows processes started with foreign token inherit the wrong environment [CVE-2019-11888]

Passing a nil environment but a non-nil token to os.CreateProcess results in the new potentially unprivileged process inheriting the parent potentially privileged environment, or results in the new potentially privileged process inheriting the parent potentially unprivileged environment. In the former case, it's an infoleak. In the latter case, it's a possible EoP, since things like PATH could be overwritten.

/cc @alexbrainman @ianlancetaylor

Should probably backport this.

@gopherbot Please open a backport to 1.12.


text:
x/tools/gopls: swallow hover errors

Please answer these questions before submitting your issue. Thanks!
What did you do?
moved the cursor around in Emacs
What did you expect to see?
Nothing
What did you see instead?
Several errors like the following:
LSP :: no identifier found [19 times]

Build info
version v0.1.1, built in $GOPATH mode

Go info
go version go1.12.6 linux/amd64

GOARCH="amd64"
GOBIN="/home/jorge/go/bin"
GOCACHE="/home/jorge/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jorge/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build604366083=/tmp/go-build -gno-record-gcc-switches"

This was reported at emacs-lsp/lsp-mode and it was said that this is on the server's fault per LSP specification: https://github.com/emacs-lsp/lsp-mode/issues/751#issuecomment-480586806

It's particular annoying in emacs due to the way it makes emacs-lsp spam the echo area with the error, wiping out other useful messages.
I just patch it locally to make:
https://github.com/golang/tools/blob/dd7c7173f160f55e5c8583101f0e9ae2b7c4ce57/internal/lsp/hover.go#L31 -> return nil, nil
to silence this, as it seems hover should not be returning errors in this case, or at least the "no identifier found" case

@zclark - feel free to contribute your package as a CL, if you're interested in doing so. I'm sorry that this issue hasn't been addressed yet, but you're totally right - that is the correct solution.

@stamblerre I made a pull request based on @zclark suggestion

authors: shackra stamblerre zclark