在同一台机器上，第二位矿工抛出“恐慌: ethash_full_new IO或内存错误”。

Question

我在Win7上使用geth1.4.18稳定-c72f5459。

我使用以下参数启动我的节点：

geth.exe --datadir \work\eth\miner2 --nat none --nodiscover --networkid 1999 --mine --port 30304 --ipcpath miner2.ipc

在与同一台计算机上的其他miner节点同步之后，第二个矿工在开始挖掘自己时崩溃。

到目前为止，我的最佳猜测是，这两个实例在存储DAG的AppData\漫游\Ethash中存在冲突。我在寻找一个选项来传递一个不同的位置到geth，但看起来这条路径是硬编码的。

panic: ethash_full_new IO or memory error

goroutine 387 [running]:
panic(0xbce660, 0xc0431f4b80)
        /usr/local/go/src/runtime/panic.go:500 +0x1af
github.com/ethereum/ethash.(*dag).generate.func1()
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:273 +0x695
sync.(*Once).Do(0xc0433b5860, 0xc043433bd0)
        /usr/local/go/src/sync/once.go:44 +0xe2
github.com/ethereum/ethash.(*dag).generate(0xc0433b5840)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:277 +0x53
github.com/ethereum/ethash.(*Full).getDAG(0xc0421de330, 0xa3, 0xc04343fc80)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:333 +0xa7
github.com/ethereum/ethash.(*Full).Search(0xc0421de330, 0x127d300, 0xc043438900, 0xc04349e240, 0x0, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/Godeps/_workspace/src/github.com/ethereum/ethash/ethash.go:338 +0x7b
github.com/ethereum/go-ethereum/miner.(*CpuAgent).mine(0xc0433c3720, 0xc0433ac340, 0xc04349e240)
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:121 +0x13a
created by github.com/ethereum/go-ethereum/miner.(*CpuAgent).update
        /go/src/github.com/ethereum/go-ethereum/build/_workspace/src/github.com/ethereum/go-ethereum/miner/agent.go:90 +0x15a

Answer 1

--autodag=false不能工作，因为一旦矿工是明星，自动预生成就会打开。如果我通过控制台调用miner.stopAutoDAG()，也会发生这种情况。

问题似乎是第二个矿工无法读取DAG文件，因为第一个矿工持有一个锁。通过shell，我试图在第一个矿工运行时调用DAG文件上的md5sum，我得到了md5sum: can't open 'full-R23-0000000000000000': Device or resource busy。

到目前为止，唯一对我有效的解决方案是启动第二个具有不同Windows帐户的矿工。

Answer 2

正如你所猜测的，问题来自DAG。

我认为geth实例同时生成两个DAG。所以您可以通过运行geth --autodag=false或geth makedag 0 /ethdata/来禁用它。

Answer 3

我的远程中也有同样的问题

我把它解决了

( 1)校验geth位(32/64 )--我有64位的系统，运行32位的geth位，因此面临着这个问题。

2)检查存储大小，我有一个Azure VM，其内部内存/RAM大小仅为3.5GB，不足以生成和存储DAG。