We’re rewarding the question askers & reputations are being recalculated! Read more.
42

Summary After the Byzantium fork, eth.getTransactionReceipt(...) will return a status field. The status field has a value of 0 when a transaction has failed with the REVERT opcode and 1 when the transaction has succeeded. Update Oct 10 2017 Responding to the comment by @thomas-jay-rush, when a transaction fails for a reason other than REVERT (i.e. THROW), ...


27

Inside truffle.js, add ,gas: 4600000 Don't forget the little "," so it looks like networks: { development: { host: "localhost", port: 8545, network_id: "*", gas: 4600000 }


24

The best way is simply not to clear them. In many (most?) situations, the array varies in size over time, and emptied slots will eventually be filled again. Instead of shortening the array, keep a separate count of live elements: uint numElements = 0; uint[] array; function insert(uint value) { if(numElements == array.length) { array.length += ...


21

All gas is consumed because the EVM essentially only has 1 exception: Out of Gas. To see this clearer, take a look at the difference between a "pure" exception, and an error due to bad/buggy/invalid EVM code. Out of Gas is the former. Now there are errors such as stack underflow, invalid JUMP, and invalid opcode: they can be called "exceptions" but they ...


15

In Solidity, by default, yes. On the EVM-level, a throw (bad jump, out-of-gas, or any other exception) only reverts the call it is inside. Solidity helpfully continues the exception down the stack until everything is undone. It is possible, using lower-level code (specifically, address.call()), to prevent this. Here is an example of this being used as an ...


14

Using etherscan blockchain explorer In etherscan, look for the TxReceipt Status which will have Fail in red, or Success in green. Example of a failure: https://ropsten.etherscan.io/tx/0x67a5f6442f49a5da6ff8682250a8eef899d9dc0c5adf20b683709433902b5956 Using the receipt eth.getTransactionReceipt(transactionHash) will return a status field that has a value ...


14

Malformed instructions are only one cause of bad JUMPDEST errors. The far more likely cause is an exception while calling another contract. When you call another contract in Solidity, it compiles in a check to see if an error occurred in the call. If an error occurred, the transaction needs to be rolled back by causing another error. The Solidity compiler ...


14

Correct, it rolls back. Except for one thing: it gives the miner all the gas, you don't get that back. That's what keeps attackers from spamming, and it's fair anyway because the miner still had to do the computation you did pay for, even though you didn't include enough gas to finish.


12

There currently isn't a clear signal that you've run out of gas. A log message is being added to some future release. Currently what I do is check to see if gasSent == gasUsed. This requires your code to remember the amount of gas you sent on a particular transaction and wait for the transaction to be mined. If gasSent == gasUsed, you most likely ran out ...


12

"Call" is an overloaded term because it is one form of invoking a contract (see What is the difference between a transaction and a call?) and it depends where the invocation is performed, in relation to the Ethereum Virtual Machine (EVM). Outside the EVM (eg web3.js) The question's contract.method.call({gas: 1000000000}) deals with web3.js, which is ...


11

The Solidity throw instruction gets compiled to an invalid JUMP instruction (i.e. a jump to an invalid location). The section 9.4.2 of the Yellow Paper explains how exceptional halting works, in chapter 8 it explains that no gas is refunded in this case. In chapter 8 it states: Just as with contract creation, if the execution halts in an exceptional ...


10

In part I believe this was a security decision to ensure spamming the network with bogus transactions cost the sender gas. For instance, if gas was refunded after a throw, a malicious actor could create a contract that consumed some gas and then would throw. That actor could then send one or many transactions with a high gas price and a lot of gas, making ...


10

If you look at the VM trace, you can see that the 100 Finney transactions ran into Out-of-Gas exceptions. In the case of an exception, all value included in the transaction is returned to the sender. To answer the second part of your question, I would use http://live.ether.camp as your block explorer, since it shows contract-produced transactions and ...


10

Since block 4370000 (Byzantium) eth.getTransactionReceipt(transactionHash) will return a status field that has a value of 0 when a transaction has failed and 1 when the transaction has succeeded. Here's an example showing the status field: { blockHash: '0xb1fcff633029ee18ab6482b58ff8b6e95dd7c82a954c852157152a7a6d32785e', blockNumber: 4370000, ...


10

To complement @Matthew's answer, it depends on how the call is made in Solidity. If C calls D.foo(), and foo does a throw, then yes the entire transaction is reverted. If C does a "lower-level raw call" like D.call(bytes4(sha3('foo()'))), and foo does a throw, then only foo and its subcalls are reverted. This is because a raw call does not propagate any ...


10

First check your account balance : balance = web3.eth.getBalance(someAddress); then try to specify the gaslimit contractInstance.createProposal("ADHD", "Foo", 2, {from: web3.eth.accounts[1], gas:3000000})


8

There is a general gas cost rule that states that sending message to any non-existing account costs more than sending message to an existing account. That also applies to the accounts of the precompiled contracts. To not pay higher costs of the message you need to create the destination account before. That is the reason why some test/private genesis ...


8

Jumps to invalid jump destinations are generated only for (explicit or implicit) exceptions. An explicit exception is when you use the keyword throw. Implicit exceptions happen for runtime errors: array access out of bounds failed sub-call (due to any reason reported by the EVM including invalid jump dest in the sub-call) ether sent to a library fallback ...


7

The throw instruction is a EVM hack that reverts all changes made by current contract execution. It exploits exceptional termination of EVM which also consumes all gas.


7

An easier to interpret trace can be seen here at ether.camp. What happened is that the contract tried to call another contract, specifying a gas quantity of self.gas - 34050. Since your execution had less than that much gas remaining at the time it was called, the result was a negative number, which translates into a very large positive number in unsigned ...


7

The target block gas limit was PI million, but was increased to 1.5 PI million (4,712,388) in Homestead. If you exceed the limit, in Geth, you will get error "Exceeds block gas limit" and the transaction will not be sent to miners. Other clients probably have a similar error. If my gas cost is 4,141,592 for example can 3,141,592 be paid in one block ...


7

Understanding this puzzle can be instructive. The behavior can be explained by the way the CALL instruction works in terms of gas. We can compare the transactions VM traces here: OK: https://live.ether.camp/transaction/7cd52325c0945d/vmtrace#65 KO: https://live.ether.camp/transaction/cd31481b4dd941/vmtrace#65 (Links are to program counter just before the ...


6

Try changing contracts['CrowdFunder'].contract.contribute({ value: web3.toWei(0.000000000000000005, 'ether') }); to contracts['CrowdFunder'].contract.contribute({ value: web3.toWei(0.000000000000000005, 'ether'), gas: 100000 }); Refer to the example under Contract Methods in JavaScript API - web3.eth.contract. And modifying the call as ...


6

I believe in some cases cumulativeGasUsed is not accurate due to spending gas / refunding gas. If at any point the contract gets above the gasLimit, it will fail with an Out of Gas exception. If a refund is issued later in the contract, it will bring the cumulative gas down even though it rises above what you think is the "gas limit" during the execution of ...


6

You don't. You can specify the gas exactly and it should go through just fine. The only gotcha is that if the contract state changes that you're executing against, and it would require more gas than provided by even a single unit, you'll lose all the provided gas and the transaction will be rolled back.


6

The entire operation did not revert because enough gas was provided by the transaction origin of the overall transaction. If insufficient gas was provided, then you would observe the behavior you were expecting, where both internal transactions would be reverted. The second internal transaction was reverted because it ran out of gas. To detect this, the ...


6

Yes, nodes relay the transactions by default. Transactions are relayed before they are executed and their gas consumption and behavior is determined. Nodes just do a basic check such as: is the signature valid? does the sending account have enough Ether to pay for the gas? is the gas below the block gas limit? If the basic checks pass, the node relays ...


5

The transaction ran Out of Gas, as can be seen on https://live.ether.camp/transaction/abddd676a2dc65dc4790463121bd77cafce4e0fb878d0b386556b055e0cae2d0/vmtrace#0 Here's the transaction where the 100 Finney was sent and it shows "Gas Limit" is 21000: https://live.ether.camp/transaction/abddd676a2dc65 So the user (0xbf27f..) specified that the transaction can ...


5

Just to clarify to the above question, Etherscan now does show if there is an error during the contract execution. A red remark indicates an error and a green remark indicates a confirmed contract invocation. Most of the exceptions for failed contracts are due to "out of gas". And as PaulS + mKoeppelmann has stated above, one way to determine if you have ...


5

So you transaction did went trough in the sense that it was broadcasted to the network and included in a block. However - as you have already suggested the gas you payed was not sufficient for this transaction. To prevent corrupted states in this case all the effects a transaction has will be rolled back. The only effect is that costs for the gas (in Ether) ...


Only top voted, non community-wiki answers of a minimum length are eligible