gobench's People
Forkers
nicolasdilley charlesxsh fredericktutu ict-tianqi 9iang22 carlosrosuero zzctmac curiousl1 dhrutijoshi11 bozhen-liugobench's Issues
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.
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.
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?
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
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.