When calling a contract function that calls into a library, the Ether sent in the transaction is spent multiple times.
Failing testrpc test case added in this PR: https://github.com/ethereumjs/testrpc/pull/123
The code deploys a contract that calls into a library and sends 1 Ether to that function. When checking the balances, 2 Ether will have been spent.
The test will fail with the message
Amount spent should be (close to) 1 Ether, but is 2.000000000000014
Alternatively, here is a minimal complete example project using web3-loader: https://github.com/graup/testrpc-library-testcase
I also tested the example code against a geth testnet instance, which works as expected.
library Lib {
function something(int self) {
self = self + 1;
}
}
contract Main {
using Lib for int;
int foo;
function Main() {
}
function doSomething() {
foo.something();
}
}
master (9a991e4)I figured out how to show the same problem with a failing test in the testrpc code base. I will update the issue in a moment.
This appears to be true even if the library call is doing nothing at all (see here)
It seems like this issue isn't getting a lot of attention, but it really needs to be. Anyone doing serious development using Solidity is surely using libraries, and this makes writing (sensible) tests with testRPC impossible if ether transactions are used.
On my list. If someone else would like to take a stab at it it'd be much
appreciated.
On Aug 12, 2016 8:37 AM, "area" [email protected] wrote:
This appears to be true even if the library call is doing nothing at all
(see here
https://ethereum.stackexchange.com/questions/7975/sendtransaction-results-in-double-send-with-arbitrary-library-call
)It seems like this issue isn't getting a lot of attention, but it really
needs to be. Anyone doing serious development using Solidity is surely
using libraries, and this makes writing (sensible) tests with testRPC
impossible if ether transactions are used.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ethereumjs/testrpc/issues/122#issuecomment-239480117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFp1cq75kncjxsbd4mg-A7YVw-r_afpks5qfJMfgaJpZM4JMvgh
.
@tcoulter: I'm happy to take a look. Any hints about where in the codebase the problem might be?
It most likely lives in the bowels of ethereumjs-vm, which handles transaction processing and the management of Ether. If it's not there, then the TestRPC is mangling/misinterpreting input somewhere.
I'm not always thrilled about mucking around in the bowels of anything, but I'm always willing to roll up my sleeves and try!
Thanks @raineorshine! Input mangling is definitely the easier option to rule out. Once you dive into ethereumjs-vm, let me know how I can help.
This has been fixed in ethereumjs-vm for quite some time but is blocking on some updates from their end. I'm going to consider running on custom fork unless these changes can get merged: https://github.com/ethereumjs/ethereumjs-vm/pull/84
CC @axic @wanderer
Hello.
I'm using testrpc 4.0.1.
I have a contract with a payable function that call a function stored in a library.
I've noticed that the value is spent twice. A similar problem reported in this issue.
When I use Geth as private network, my implementation works as expected.
Is this multiple spent problem when calling a lib on testrpc has a fix or a workaround?
Thanks
@eloudsa this should be fixed by building testrpc with ethereumjs-vm 2.1.0 (testrpc is currently using ethereumjs-vm version 2.0.1 in the yarn.lock file).
Hi,
This issue is a blocker for us now.
Was anyone able to come up with a reasonable workaround until it's fixed?
Thanks
@szerintedmi I believe it's fixed in TestRPC v4.
For v3, I have been using a forked TestRPC for months: https://github.com/raineorshine/testrpc. It has the fix in this commit: https://github.com/raineorshine/ethereumjs-vm/commit/6d1e058ba948e7d92fa75c2b1cc83086b5a5bfe7.
@raineorshine : I'm using latest 4.0.1 and it's still there
Thank you for fork tip, I give them a try!
UPDATE: amazing, works fine with that fork, thanks a lot!
This will be fixed in the TestRPC in the next release, set for Monday, Aug. 21st.
I can confirm it's fixed with 4.1.0 release . Can be closed from my part.
Thank you!
Thanks for the confirmation! Closing this ticket. Thanks everyone involved for getting this figured out!
Most helpful comment
This will be fixed in the TestRPC in the next release, set for Monday, Aug. 21st.