Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

go test hangs #308

Open
rjkroege opened this issue Jul 26, 2020 · 6 comments
Open

go test hangs #308

rjkroege opened this issue Jul 26, 2020 · 6 comments
Assignees

Comments

@rjkroege
Copy link
Owner

On Go 1.14.5 on MacOS Catalina 10.5.6, go test hangs. Fix this?

@rjkroege
Copy link
Owner Author

TestXCmdPipeMultipleWindows hangs.

@rjkroege
Copy link
Owner Author

Timeout spew:

=== RUN   TestXCmdPipeMultipleWindows
panic: test timed out after 10m0s

goroutine 15 [running]:
testing.(*M).startAlarm.func1()
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1459 +0xdf
created by time.goFunc
	/usr/local/Cellar/go/1.14.5/libexec/src/time/sleep.go:168 +0x44

goroutine 1 [chan receive]:
testing.(*T).Run(0xc00022b9e0, 0x15c6c83, 0x1b, 0x15e0c00, 0x10c2201)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1043 +0x37e
testing.runTests.func1(0xc000200000)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1284 +0x78
testing.tRunner(0xc000200000, 0xc000185de0)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:991 +0xdc
testing.runTests(0xc000126160, 0x1a11b20, 0x84, 0x84, 0x0)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1282 +0x2a7
testing.(*M).Run(0xc00011e100, 0x0)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1199 +0x15f
github.com/rjkroege/edwood.TestMain(0xc00011e100)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/fsys_test.go:58 +0x7f
main.main()
	_testmain.go:304 +0x135

goroutine 70 [chan receive]:
github.com/rjkroege/edwood.runpipe(0xc000100520, 0xc00000007c, 0xc000076be8, 0x3, 0x20, 0x1)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd.go:504 +0x2b2
github.com/rjkroege/edwood.pipe_cmd(0xc000100520, 0xc00012a7d0, 0x0)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd.go:531 +0x9e
github.com/rjkroege/edwood.cmdexec(0xc000100520, 0xc00012a7d0, 0x0)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd.go:109 +0x399
github.com/rjkroege/edwood.filelooper(0x0, 0xc00012a780, 0xc00012a701)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd.go:843 +0x162
github.com/rjkroege/edwood.X_cmd(...)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd.go:462
github.com/rjkroege/edwood.TestXCmdPipeMultipleWindows(0xc00022b9e0)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/ecmd_test.go:63 +0x3d5
testing.tRunner(0xc00022b9e0, 0x15e0c00)
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:991 +0xdc
created by testing.(*T).Run
	/usr/local/Cellar/go/1.14.5/libexec/src/testing/testing.go:1042 +0x357

goroutine 72 [chan send]:
github.com/rjkroege/edwood.runwaittask(0xc00010f200, 0xc00022ccc0)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/exec.go:819 +0xb7
created by github.com/rjkroege/edwood.run
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/exec.go:652 +0x172

goroutine 14 [chan send]:
github.com/rjkroege/edwood.runproc.func4(0xc0000d8580, 0xc00000e4e0)
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/exec.go:1012 +0x6c
created by github.com/rjkroege/edwood.runproc
	/Users/rjkroege/tools/gopkg/src/github.com/rjkroege/edwood/exec.go:1009 +0x87a
exit status 2
FAIL	github.com/rjkroege/edwood	600.443s

Conceivably this is a notarization / quarantine / process namespace issue on modern MacOS. Presumably it will be worse under Big Sur.

@rjkroege
Copy link
Owner Author

This seems to be happening on Ubuntu and MacOS on the builders. Presumably we have a race condition. Sigh.

@rjkroege rjkroege self-assigned this Apr 13, 2021
@rjkroege
Copy link
Owner Author

Related to #291 in some fashion.

@paul-lalonde
Copy link
Collaborator

Are we going to fix it, or will we temporarily disable this test until it gets fixed (magical thinking)?

@rjkroege
Copy link
Owner Author

I was going to get around to it. 😀 But after some preliminary investigation,
I realized that it would need some considerable time to dive in and I just
never seemed to have a whole day to do nothing but think about thread
ordering issues.

You're right: probably I should just disable for the present.

rjkroege added a commit that referenced this issue Aug 21, 2021
Before getting to #308 for real, temporarily suppress failing
test TestXCmdPipeMultipleWindows.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants