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

Data Race in dialScheduler #23965

Closed
SecTechTool opened this issue Nov 24, 2021 · 1 comment
Closed

Data Race in dialScheduler #23965

SecTechTool opened this issue Nov 24, 2021 · 1 comment
Labels

Comments

@SecTechTool
Copy link

System information

Geth version: 1.10.9-unstable-9ada4a2e-20210910
OS & Version: MacOS
Network: Private test net

Expected behaviour

node run normally

Actual behaviour

Data race in dialScheduler

Steps to reproduce the behaviour

  1. setup a 10-node private geth nodes lcoally
  2. setup a fuzzing node continually sending fuzzed messages to other 10 normal geth nodes.
  3. After more than 24 hours fuzzing experiment, one of the geth node who is run in fast mode crashed down.
    The running command for the node is ./build/bin/geth --identity "ETH-node10" --datadir "node10" --ethash.dagdir "node10" --port "30312" --maxpeers 15 --networkid 10086 --syncmode "fast" --bootnodes "enode://e71bec68f09c4b9567bd4575d855ea61b179b1d64e6f78c861ebddf3783178f95edaaf39647c1f792bc654d0931ad25415d50c25c437787183c0b0a32a76da85@127.0.0.1:0?discport=30301" --mine --miner.etherbase 0xd192415624a039b24ad571f96cb438de9f0556a7 --miner.threads 1 console

Backtrace

image

@holiman
Copy link
Contributor

holiman commented Nov 24, 2021

Yup, but this is a duplicate of #23430

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants