[01:18:49] I can't really think of a clean way to do this, I guess I'll just commit and push my test, let me know what you guys think. [01:22:58] Also, for some reason, the test randomly fails [01:23:07] I can't figure it out [01:23:22] I think it has something to do with the stakes not being mature [01:23:35] But I added slow_gen() after the stake [01:23:47] So that should have taken care of the take confirmations right? [01:23:55] Or am I understanding this wrong? [01:24:13] Anyways, I've pushed the unit test to my fork. [01:24:19] @prole some of the interns had experience with this, could you tag him? [01:26:08] But on my manual testing seems that my fork is fully working in terms of the 2 issues with the transaction amounts + the stake report [01:27:18] BTW, I had to add some updates to the src/wallet/rpcwallet.cpp as it was causing navcoin-cli to not return the correct values for the report as well. [01:27:40] As for navcoin-qt, how would we go about automating the test for that? [01:31:16] maybe it’s easier to test unit GetsStakeSubTotal() [01:31:32] 3:31am here, heading to bed now [01:32:50] Hmmm, that might be easier, but I really think it would be best to test the actual RPC call. [01:33:10] Yeah, I'm heading to bed too [01:33:28] @prole @aguycalled please check out my test and let me know if you spot anything wrong with it. [01:33:57] I really think it's the maturity of the stake (Which would explain why sometimes the report does not include the new stake) [01:34:07] Then the test fails because of it. [01:34:11] Anyways, TTYL [01:37:22] the tests should be deterministic, stakes always mature at the same height [01:37:56] havent looked at your test yet, will do tomorrow [01:53:11] Ok, thanks [03:13:21] @prole , @aguycalled Good news, I found the issue that was causing my test to randomly fail [03:13:33] I pushed the fix [03:13:45] And it's building in travis-ci as I type. [03:13:52] 🤞 😄 [03:14:58] Btw, I also created a few other PRs for UI changes, namely: https://github.com/NAVCoin/navcoin-core/pull/454 https://github.com/NAVCoin/navcoin-core/pull/453 [03:15:10] And a PR for the build-unix.md file https://github.com/NAVCoin/navcoin-core/pull/452 [03:15:24] Talk to you guys later [04:10:54] @prole @aguycalled Seems my test works now [04:11:03] But on the 64bit build for linux [04:11:08] It get's a lock error [04:11:11] Assertion failed: lock cs_main not held in ../../src/wallet/wallet.cpp:4250; locks held [04:11:29] This error does not happen on my local testing though, so I'm not sure how to fix it. [06:18:01] Thanks so much for helping! You're the kind of hero the NavCoin community needs right now ❤️ [06:18:27] Ill fire up the PRs and see if I can replicate the error [10:13:54] there might be a function calling SetMerkleBranch() which does not LOCK(cs_main) [10:14:32] if you ./configure --enable-debug you will see more info about locks [10:14:33] https://github.com/NAVCoin/navcoin-core/blob/master/doc/developer-notes.md [10:14:41] @mxaddict [12:58:35] Is there a way to replicate the error on my local machine? [12:58:52] Cause it only happens on the 64bit travis test [12:59:04] on the 32bit/i386 test it runs fine. [12:59:47] @aguycalled , what does "utACK" mean? [13:01:54] Nvm, I found the definition of utACK 😄 [16:07:02] @aguycalled the issue is that the error does not happen on my local machine [16:07:27] I'm able to run the test fine locally, and it also seems to work fine on the i386 build on travis [16:07:43] It's only failing on the x86_64 build [16:36:18] @prole have any idea what could cause the issue? [16:36:59] This is my local run of the same test: ./qa/pull-tester/rpc-tests.py getstakereport ............................................................................................................................................................................................... ..... getstakereport.py: Initializing test directory /tmp/test04deo_mv/0 Stopping nodes Cleaning up Tests successful Pass: True, Duration: 98 s TEST [16:37:00] | PASSED | DURATION getstakereport.py | True | 98 s ALL | True | 98 s (accumulated) Runtime: 98 s [16:37:45] So it works locally, but fails on travis-ci when building and running the test on the x86_64 platform [16:58:16] BTW, I noticed that some tests in the suite take a long time to finish [16:58:39] I'm guessing that it because the block time in devnet is still 30 seconds [16:58:56] Do you think it might be a good idea to lower that to something like 5 or 10 seconds? [16:59:14] It would shave some time off the runtime for some tests [16:59:23] Including mine 😄 [17:05:30] @prole @aguycalled let me know what you think, for now I will make the change to my branch and run the test suite, see if anything breaks [17:06:45] the difficulty is super low at the start of the network, it wont make a difference lowering the blocktime [17:08:07] It seems to make my test run slightly faster [17:08:18] 60-70 seconds instead of 90-110 seconds [17:10:53] Also, I noticed that we don't seems to have maturity setting in the chain params, is this by deisng? [17:12:24] I mean this: /** Coinbase transaction outputs can only be spent after this number of new blocks (network rule) */ static const int COINBASE_MATURITY = 50; [17:12:46] this is used for the coinstake too [17:12:57] i think [17:13:01] let me check [17:13:30] I was thinking maybe if we could lower this value for devnet, then the stakereport and other tests can be make more efficient [17:13:33] Cause right now [17:13:37] yes [17:13:43] For the staked blocks to show on the stakereport [17:13:47] They need 50 confirmations [17:13:59] have nothing against [17:14:07] That that is the step that runs right before the step that fails on my test in travis-ci [17:14:36] i'm not really sure why that lock does not held for the travis test, it should not depend on the arch [17:15:05] I think what might be happening is the navcoind instance that is being used to create the 50 blocks to confirm the stake is hanging. [17:15:32] Which might exlain why the getstakereport can't get a lock (cs_main) [17:15:56] It might not have to do with the arch [17:16:12] Might just be that 64bit uses slightly more resources than 32bit binaries [17:16:38] If my assumption is correct, the instances that run the 32bit and 64bit tests have same resources [17:17:05] So if the 64bit uses more and runs out of RAM or IOPs or CPU cycles, then the navcoind could hang and not get a lock? [17:17:24] IDK if it's actually the cause, it's just a suspecion. [17:18:13] I suspect if I do a node.generate(1) time.sleep(1) for 50 times, it would pass the test (I will try it now) [18:19:31] @aguycalled @prole check my commit on moving COINBASE_MATURITY over to Consensus::Params [18:19:32] https://github.com/NAVCoin/navcoin-core/pull/450/commits/e8b683942df1730042233c1e1248aad6b374d138 [18:19:37] Let me know what you think [18:19:56] Damn, that's an old photo of me 😄 [18:23:12] share the new one 😃 [18:23:44] you looks young Laurence Fishburne 😃 [18:24:08] looks initially good, added 2 comments [18:26:42] @aguycalled I don;t see your comments. [18:30:09] NVM, I see them [20:06:14] @mxaddict the tests are failing on my osx because of the lock, i'll try to debug it further [20:06:33] Hmmm [20:06:41] That's strange [20:07:01] I don't get the lock fail on my machines [20:07:08] I tried both at home and on my laptop [20:07:15] osx? [20:07:22] No, linux both [20:07:41] But the test that was failing on travis-ci was linux 64bit [20:32:25] @sakdeniz LOL, MORPHEOUS! [20:43:15] @mxaddict i'm remembering i also had some problems with that concrete lock while working on zeroct, let me look for the fix [20:46:26] mm nope, its not the same [21:17:07] @mxaddict ive just invited you to the NavCoin Development Team on GitHub. This means you're able to review and approve PR's on the repo now [21:25:12] @dy5es41, @A-B and @Hayden i also added you guys on there too. so you might see your self get requested for PRs. Feel free to review if you have time between your Uni work