timmyyuan / gobench Goto Github PK

View Code? Open in Web Editor NEW

21.0 21.0 10.0 862 KB

Makefile 0.57% Go 63.53% HTML 2.34% Dockerfile 32.96% Python 0.61%

gobench's People

Contributors

Stargazers

Watchers

Forkers

nicolasdilley charlesxsh fredericktutu ict-tianqi 9iang22 carlosrosuero zzctmac curiousl1 dhrutijoshi11 bozhen-liu

gobench's Issues

A potential new introduced bug due to misusing condition variable in goker/blocking/kubernetes/58107

blocking position: https://github.com/timmyyuan/gobench/blob/master/gobench/goker/blocking/kubernetes/58107/kubernetes58107_test.go#L47
Because the cond.Signal() and cond.Wait() execute concurrently without control. In a situation, the cond.Signal() executes first, then the cond.Wait() executes in G1 or G2. In that case, there is no Signal() can awaken the Wait(), which will result in goroutine leak. Sometimes the precedure can run normally, but the bug is easy to be triggered as well.

Possible intervening

/// main 						     G1                         	    G2	                         
/// ...						             ...			            ...
///startResourceQuotaController()                                                
///go resourceQuotaController.Run()                                              
///resourceQuotaController.HelperSignals() 											
/// rq.queue.Put()					 go rq.worker(rq.queue, "G1")()   go rq.worker(rq.missingUsageQueue, "G2")()                
/// rq.missingUsageQueue.Put()                           queue.Get()                      queue.Get()    
/// q.cond.Signal()		                                         
///                                                      q.cond.Wait()                    q.cond.Wait()

[Data Race]: potential new initroduced data race in Serving#3068

A new data race in serving#3068:

WARNING: DATA RACE
Read at 0x00c0000701f0 by goroutine 9:
  runtime.chansend()
      /usr/local/go/src/runtime/chan.go:158 +0x0
  command-line-arguments.(*impl).Go()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:44 +0x84
  command-line-arguments.TestServing3068.func1()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:65 +0x4b

Previous write at 0x00c0000701f0 by goroutine 7:
  runtime.closechan()
      /usr/local/go/src/runtime/chan.go:355 +0x0
  command-line-arguments.(*impl).Wait.func1()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:49 +0x64
  sync.(*Once).doSlow()
      /usr/local/go/src/sync/once.go:68 +0x109
  sync.(*Once).Do()
      /usr/local/go/src/sync/once.go:59 +0x68
  command-line-arguments.(*impl).Wait()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:48 +0x64
  command-line-arguments.TestServing3068()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:72 +0x13b
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1203 +0x202

Goroutine 9 (running) created at:
  command-line-arguments.TestServing3068()
      /home/ubuntu2004/goProgram/src/GTrack/testdata/nonblocking/serving/3068/serving3068_test.go:63 +0x127
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1203 +0x202

Goroutine 7 (running) created at:
  testing.(*T).Run()
      /usr/local/go/src/testing/testing.go:1248 +0x5d7
  testing.runTests.func1()
      /usr/local/go/src/testing/testing.go:1521 +0xa6
  testing.tRunner()
      /usr/local/go/src/testing/testing.go:1203 +0x202
  testing.runTests()
      /usr/local/go/src/testing/testing.go:1519 +0x612
  testing.(*M).Run()
      /usr/local/go/src/testing/testing.go:1427 +0x3b3
  main.main()
      _testmain.go:43 +0x236

In addition, since the Goroutine 9 and Goroutine 7 are called in parallel, the two statements i.wg.Add(1) and i.wg.Wait() will be called in parallel, it can cause a data race.

Grpc862 in goker failed to repro

gobench/gobench/goker/blocking/grpc/862/grpc862_test.go

Lines 57 to 60 in 5affb0a

 select { // Block here 

 case <-time.After(sleepTime - time.Since(connectTime)): 

 case <-ac.ctx.Done(): 

 return

It seems that G2 will not hang up forever when timeout at L58.
I failed to repro it using goleak with a little delay before leak check instead of check it immediately.

NeedProxy

Hi, when I tried to execute make pdf, I got some network problems. I found there is a NeedProxy in the code, can I use it to proxy the whole docker build and docker run processes? And how can i use it?

Potential new initroduced bug in cockroach1055&cockroach1462

I found out that goker might have introduced a new bug when reproducing cockroach1055 (https://github.com/timmyyuan/gobench/blob/master/gobench/goker/blocking/cockroach/1055/cockroach1055_test.go.)
When the program is executed according to the path s.StartTask -> s.Quiesce -> s.Stop, for the variable s.drain, the lack of s.drain.Done() will also cause the program to block.

more data races in etcd#8194

As described in backtrace, there are two operations (one is write and the other one is read) can cause a data race. However, because the Goroutine 9 and Goroutine 10 are called in parallel，we cannot determine the execution status of them.

Case 1:

Write by goroutine 9:
      command-line-arguments.testLessorRenewExtendPileup()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:14
Read by goroutine 10:
      command-line-arguments.(*lessor).runLoop()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:36

Case 2:

Write by goroutine 9:
      command-line-arguments.testLessorRenewExtendPileup()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:13
Read by goroutine 10:
      command-line-arguments.(*lessor).runLoop()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:35

Case 3:

Write by goroutine 9:
      command-line-arguments.testLessorRenewExtendPileup()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:13
Read by goroutine 10:
      command-line-arguments.(*lessor).runLoop()
            /root/gobench/goker/nonblocking/etcd/8194/etcd8194_test.go:36

That's to say, case 1-3 can also cause a data race respectively bacause of the concurrency between the two goroutines. When using Go's official data race detector, the bug that is triggered first will be detected and printed, but it cannot be denied that the other three cases are still potential data races.

[panic]: another panic in grpc#2371

As described in backtrace, the statement case <-ccb.resolverUpdateCh: causes a panic when the statement cc.resolverWrapper = nil happens before it. Does this also mean that the statement ccb.resolverUpdateCh <- struct{}{} will cause a panic with the statement cc.resolverWrapper = nil?

In addition, the func chanrecv() is manifested as write，set nil is manifested as write. Does it mean that the two statements (case <-ccb.resolverUpdateCh: and cc.resolverWrapper = nil) can cause a data race at the underlying code level. The func chansend() is manifested as read，set nil is manifested as write. Does it mean that the two statements (ccb.resolverUpdateCh <- struct{}{} and cc.resolverWrapper = nil) can cause a data race at the underlying code level.

timmyyuan / gobench Goto Github PK

gobench's People

Contributors

Stargazers

Watchers

Forkers

gobench's Issues

A potential new introduced bug due to misusing condition variable in goker/blocking/kubernetes/58107

[Data Race]: potential new initroduced data race in Serving#3068

Grpc862 in goker failed to repro

NeedProxy

Potential new initroduced bug in cockroach1055&cockroach1462

more data races in etcd#8194

[panic]: another panic in grpc#2371

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent

	select { // Block here
	case <-time.After(sleepTime - time.Since(connectTime)):
	case <-ac.ctx.Done():
	return