testrpc falls over - "Cannot read property 'gasPrice' of undefined"? #293
Comments
|
I have exactly the same issue. However I am able to find a workaround to the problem. In my case I have two transactions to be mined in one block, and the execution of second transaction depends directly on the first one. (The first one is an initialization and the second transaction requires the contract to be initialized.) The workaround (took me a few hours although simple) is to put a delay equal to mining interval between the two transactions so that they will be mined in separate block. After doing so the error is gone. I am not sure if it is correct though, but since mine is just a local setup script for testing, I did not pursue further. |
|
@hynese thanks for reporting this! @ntulsy & @hynese - is there an immediate reason that either of you need to be using interval mining? If not, I highly recommend dropping the It seems like for some reason we've queued an invalid (undefined) transaction. I'll look into this and see what might've caused it. |
|
Same result here when using miner_stop to stop auto mining and then either calling evm_mine or miner_start after queueing a couple of contract function invoking transactions. I was not able to recreate with just ether moving transactions. NOTE: the same behavior was observed with This is using: PLATFORM: darwin EXCEPTION: APPLICATION LOG: |
|
@yarrumretep if you're keen, can you please try running this on Also would be interesting to know whether this is a problem on |
|
@benjamincburns same result. Let me see if i can make a mini-project that shows this. |
|
@benjamincburns here you go: https://github.com/yarrumretep/ganache293 Also, I noticed that if you comment out the third 'transfer' transaction, the mining will go through (no gasPrice issue). HOWEVER, it seems the evm_mine invocation will only mine 1 transaction per block (hence the 3 mine() calls). Do you want a separate ticket for the 1 transaction per evm_mine call? Also, evm_mine does not give a proper JSONRPC response (at least in the @beta) - see the mine() function which swallows the error. I think I saw this issue in another ticket... |
Not unless it's causing you trouble. This is expected behavior. I'll have a look at the project, thanks a lot for that - will make sorting this out much easier! |
|
@benjamincburns - hrm - yeah, the idea was that we would queue up some transactions and then call evm_mine to cause them to be mined in the same block. We are looking to exercise conditions in our contracts which could be an issue if multiple transactions executed in the same block. Would it make sense to see about getting the evm_mine call to do as many xas as will fit? Or is there some other strategy for doing this sort of testing? |
@yarrumretep just to help me understand how people are using ganache, can you please explain why you're doing this? Most people don't tend to want or need to control the creation of blocks within Ganache in this way |
|
Looks like you might've already answered my question! Can you elaborate a bit on those "conditions in [your] contracts which could be an issue if multiple transactions executed in the same block?" I'd love to understand further. Edit: Also if you have need for testing multiple transactions in one block, please raise an issue for that, as it sounds like our current way of doing things is problematic for you. |
|
Hi @benjamincburns - yeah, any time you condition based on block.number (as you might, for instance, if you are using minime style Checkpoint structures), you could run into problems with 'concurrent' (same block) transaction mining. We want to be able to synthesise these sorts of diabolical conditions to build robust test suites. |
|
Sounds like a problem to avoid altogether if possible! Either way, see the edit to my last comment - sounds like you should raise that issue, and I'll look into why we're crashing here! |
|
See this comment: trufflesuite/ganache#108 (comment) Seems to imply that evm_mine should pick up as many transactions as will fit in a block - which is analogous to what a real-world miner might do, right? |
Sounds like he either never got around to that, or we (I?) broke it after the fact. I'll double check the code, but I think even when calling |
|
https://github.com/trufflesuite/ganache-core/blob/develop/test/mining.js#L169-L204 Edit: I just added the check and the test passes - it seems that we do mine multiple transactions into one block. However I don't think this occurs if you call Edit2: also I misread that test to begin with - he checked that the current block number only advanced by 1 after those transactions. Also I replaced |
|
If you're only getting one TX per block, I suspect you're running into this scenario. Try increasing your block gas limit: https://github.com/trufflesuite/ganache-core/blob/develop/test/mining.js#L249-L286 |
|
@hynese thanks for reporting this one, and @yarrumretep thanks for that sample project, it was really illustrative, and I learned a lot from our conversation! @yarrumretep I've confirmed that with this change your test should work, and that you should only need to call The fix in 8e080b4 will go out with our next release! |
|
this is great @benjamincburns - thank you for the quick fix. When do you think the next release will be released? In the meantime, is there a straightforward way for us to use the development version of ganache-core with ganache-cli? |
Yes, have a look at the In short, you'll want to clone both cd $PARENT_DIRECTORY/ganache-core
npm install
npm link
cd ../ganache-cli
npm install
npm link ganache-core
npm run build
npm start |
I'm getting the following failure of testrpc:
I'm running
testrpc -b 3truffleis driving a test script. I'm totally stuck by the failure/error and can't see a way forward...Your Environment
node v6.10.2
OSX 10.12.4
testrpc v3.0.3
The text was updated successfully, but these errors were encountered: