01:58:42 .merges 01:58:42 -xmr-pr- 8632 8640 8641 8643 8644 8645 8648 8649 8651 8653 8654 8663 8671 8682 8683 8686 02:03:52 .merge+ 8677 8678 8675 8676 02:03:52 Added 02:04:35 sech1: I added both your PRs 02:05:02 we have quite a lot of changes which would make sense to tag v0.18.2.0 and also do some testing on testnet / stagenet before release 02:05:33 tag it as v0.18.2.0 instead of v0.18.1.3 06:22:07 selsta so 2-3 weeks for testing and then release? Can the release wait until February? I'm planning a P2Pool fork: https://github.com/SChernykh/p2pool/issues/224 so it would be nice to sync releases of GUI v0.18.2.0 and P2Pool v3.0. 06:35:44 sech1: yes the release can wait until February and we can do testing in the meantime 06:37:29 I'll be doing P2Pool testing too with a few other people, and I'll ask them to use the current monero release branch :) 06:40:09 we also have Dandelion++ changes 06:41:01 hope luigi can do merges soon™ :D 06:43:04 was there some progress also on community nodes? 11:06:24 rbrunner: Regarding your second point. Supposing we move to Seraphis or similar down the line. Would the approach be to convert an "old" wallet2 style multisig wallet, into a new Seraphis compatible wallet. Or... would they simply create a new multisig wallet with Seraphis, and then transfer the funds over to it 14:56:09 #no-wallet-left-behind:monero.social john_r365: 15:10:45 Domt kidding me please 15:10:48 So converting 24 words to 25 words will my 25 words match or not if someone else creates new monero wallet? For example, if it does match, what is the probability? 15:10:56 I want to answer 15:11:03 I love you monero 15:11:24 Answer me ofrnxmr 15:12:25 Ofrnxmr if you don't answer me, I will f*ck your wife as5 h0le. I will f1sting your wife as5 h0le. 15:13:03 Shes gonna fist you 😀 15:13:09 If you have no wife, I make your mom 15:13:29 Dont threaten me with a good time 15:13:37 Do you still want those pics 15:14:20 Foot pict? 15:14:21 So converting 24 words to 25 words will my 25 words match or not if someone else creates new monero wallet? For example, if it does match, what is the probability? 15:14:36 Negligible 15:14:56 Answer mee 15:15:00 So converting 24 words to 25 words will my 25 words match or not if someone else creates new monero wallet? For example, if it does match, what is the probability? 15:15:39 sorry, ignore maratov^ 15:28:36 So converting 24 words to 25 words will my 25 words match or not if someone else creates new monero wallet? For example, if it does match, what is the probability? 15:28:36 I answered, negligible is the correct term 15:29:27 I suggest not answering flaming assholes (at least after they prove to be flaming assholes). 16:33:03 .merges 16:33:03 -xmr-pr- 8632 8640 8641 8643 8644 8645 8648 8649 8651 8653 8654 8663 8671 8675 8676 8677 8678 8682 8683 8686 17:16:16 sech1: kayabanerve[m]: can you reply here so we can get this merged? https://github.com/monero-project/monero/pull/8675#issuecomment-1379186484 17:16:33 I think the comment was in regards to a different proposed solution, not the PR itself 17:19:29 yes, that's my understanding. My question is how does the current solution (cache in this pr) handle it? 17:19:39 .merges 17:19:39 -xmr-pr- 8675 8676 17:25:44 I answered 17:28:32 thanks. All merged 17:30:30 ty 17:40:58 sech1: I'm getting "Couldn't allocate RandomX light VM using large pages" and "Couldn't allocate RandomX cache using large pages" on start 17:41:02 macOS 17:42:06 You need to enable huge pages 17:42:11 or reboot if they're already enabled 17:43:59 does that even exist on macOS? and we can't expect all monerod users to enable this? 17:45:29 according https://xmrig.com/docs/miner/hugepages they're called super pages on macOS 17:46:42 this is just a warning and it monerod can work fine if it allocates RandomX without large pages (it will hash a bit slower) 17:46:56 also, this warning doesn't appear in logs by default 17:47:07 you need to enable "randomx" log catergory to see it 17:47:17 hmm ok, wait 17:47:36 I think I know the issue 17:51:05 sech1: https://paste.debian.net/hidden/8ab71a75/ 17:51:20 this is with log level 0 17:53:48 can you check bitmonero.log? It shows log categories at startup 17:54:32 New log categories: *:WARNING,net:FATAL,net.http:FATAL,net.ssl:FATAL,net.p2p:FATAL,net.cn:FATAL,daemon.rpc:FATAL,global:INFO,verify:FATAL,serialization:FATAL,daemon.rpc.payment:ERROR,stacktrace:INFO,logging:INFO,msgwriter:INFO 17:54:35 ah right 17:54:38 because it's a warning 17:55:13 but you shouldn't get these warnings all the time. It tries to allocate VM only once per thread 17:57:18 selsta so from what I can see, when it's syncing, it's checking a lot of RandomX hashes in worker threads at the same time, so you have 16 worker threads there and get 16 warnings 17:58:05 it keeps printing this message 4x 17:58:13 it printed it hundreds of times now during sync 17:58:52 everytime there is a "Synced 2782981/2797403 (99%, 14422 left)" message there are also 4x warning messages 18:01:19 that's not good 18:01:30 so it creates new threads in groups of 4 every time 18:01:45 and then allocates VMs in these threads and then these VMs leak 18:02:52 slow_hash_free_state() should be called when a thread that calculated RandomX hashes before, exits 18:03:07 it is probably the case here, but I need to double check 18:03:56 yes, it's Blockchain::block_longhash_worker() responsible for warning spam, but it cleans up everything correctly, so no memory leak 18:04:51 and the warning spam is _because_ it cleans up everything after every batch, and then tries to allocate VMs again 18:05:18 it should be an easy fix - just print a warning once 18:09:58 ok will test once you have a patch 18:16:11 selsta https://github.com/monero-project/monero/pull/8705 18:18:21 sech1: works now but is it a good idea to print this at log level 0? maybe better to move it to log level 1? 18:19:09 it's not at log level 0, it's a warning 18:19:19 and default logger settings show all warnings 18:20:13 we will get lots of reports about what this is and if randomx is broken lol 18:21:25 an opportunity to educate people about large pages :P 18:23:34 anyway, people can discuss it in 8705 now - either leave it as is, or demote it from warning to info message 18:25:49 It seems like a pointless warning to issue repeatedly. The patch seems fine. 18:30:11 -xmr-pr- SChernykh opened pull request #8706: RandomX: print VM allocation warnings only once 18:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8706 18:30:11 -xmr-pr- SChernykh opened pull request #8705: RandomX: print VM allocation warnings only once 18:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8705