01:11:50 <hyc> are mining test failures a known issue? https://github.com/monero-project/monero/actions/runs/2707319829
01:13:33 <selsta> this fails occasionally on CI, like every 10 runs
01:15:03 <selsta> Couldn't stop mining due to unknown error.
01:25:07 <hyc> ok
01:46:20 <binaryFate> <selsta> binaryFate has to send a monero-announce mail <--- (cc sethforprivacy) I want to keep the announce list as clean as possible in terms of S/N ratio. Hence I'll give ~3 days for people to use new version and provide large scale testing before announcing anything on that list.
01:48:14 <selsta> sounds good
01:50:23 <binaryFate> historically we often had minor releases to fix last minute bugs, and I don't wan't to announce multiple required updates back to back, so just making (more) sure we're announcing the right thing. 3 days won't change anything wrt. hard fork date in terms of preparation.
01:52:39 <sethforprivacy> binaryFate: Understood, thanks for the context! Just wanted to make sure it wasn't forgotten 🙂
01:53:46 <binaryFate> thanks for following up on tasks and please make sure I do it in 3 days :)
04:41:21 <sgp[m]> Are there any known significant issues with 0.18?
05:50:58 <jeffro256[m]> multisig is still officially experimental/unsafe, as I'm pretty sure burner bug fix hasn't been merged 
05:53:49 <TrasherDK[m]> `mpnerod` is still rather spammy, when doing background mining:
05:54:23 <TrasherDK[m]> 2022-07-21 04:24:58.107        I background mining is enabled, but not started, waiting until start triggers... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e9b6a7db686b8e32ca1f5548af8ad22a4a90a160)
09:01:24 <selsta> TrasherDK[m]: did you open a github issue for it?
09:07:16 <TrasherDK[m]> Nope. I kinda left it at Moo agreed it was too verbose 😳 It's not really anything more than annoying noise. Not a bug.
11:42:37 <moneromooo> https://github.com/monero-project/monero/pull/8450 fixes that mining test error (it was spurious).
11:46:15 <sech1> It also silences "not enough RAM" warning, was it an annoying warning?
11:46:45 <moneromooo> For me, yes. I run on VMs.
11:47:09 <moneromooo> Also, I ran into an odd failure:
11:47:36 <moneromooo> In handle_accept, Exception in boosted_tcp_server<t_protocol_handler>::handle_accept: local_endpoint: Bad file descriptor
11:47:52 <moneromooo> That kills connectivity to RPC (a longstanding problem).
11:48:42 <moneromooo> I tried adding some recovery code by closing/reopening etc and starting accepting agian, but then I get a series of similar failures, but with operation cancelled instead.
11:49:28 <moneromooo> I'm not great with net code, and this has the added layer of boost idiosyncracies so if someone want to try it, run the mining test in a loop and you should see it eventually.
12:00:51 <moneromooo> I pushed an update which makes it so you can get the verbose stuff with the MINING_SILENT=0 var.
12:10:19 <atoc> any good first issues a new dev can tackle?
12:10:37 <atoc> new to monero*
12:15:40 <moneromooo> You could go to github, look at the issues, pick something that looks simple.
12:15:43 <monero1ro[m]> I'm reading "From zero to monero 2.0" and it seems to be a good start. i
12:15:43 <monero1ro[m]> Is there a 3.0 in process?
12:15:57 <moneromooo> Or use the software, find something that annoys you in particular, and fix that.
12:17:17 <moneromooo> Oh, a good one: apparently DNS queries are slow even with well configured DNS. Fixing this would be nice.
12:17:38 <atoc> 👀
12:18:30 <atoc> is there an open issue for this?
12:19:05 <moneromooo> Probably, three was discussion of this a while back.
12:20:10 <atoc> https://github.com/monero-project/monero/issues/8440 seems like the wrong place to post this
12:20:40 <ofrnxmr[m]> ^ use scam wallet = get scammed
12:20:40 <ofrnxmr[m]> my 2c on that one 
12:21:41 <ofrnxmr[m]> New to GitHub as well I guess?
12:21:41 <ofrnxmr[m]> There is a search button
12:22:30 <atoc> didn
12:22:40 <atoc> t know you could search through issues
12:26:53 <ofrnxmr[m]> You can search through the entire repo
12:26:53 <ofrnxmr[m]> Can also search through PR's that need reviews or are incomplete etc 
12:50:09 <sethforprivacy> <jeffro256[m]> "multisig is still officially..." <- Burning bug fix was merged before release: https://github.com/monero-project/monero/commit/02cbccc52937035396614c04b4ebebe6cd1b0c8c
12:50:38 <sethforprivacy> <sgp[m]> "Are there any known significant..." <- None that I have seen yet on my nodes, main remaining user issues will be Ledger/Trezor not being usable on the newest GUI/CLI.
12:51:03 <sethforprivacy> > <@sgp:magicgrants.org> Are there any known significant issues with 0.18?
12:51:03 <sethforprivacy>  * None that I have seen yet on my nodes, main remaining user issues will be Ledger/Trezor not being usable for some time after the fork, and Ledger being entirely unusable on v0.18.0.0 until they release an updated app.
12:52:58 <sethforprivacy> <moneromooo> "Oh, a good one: apparently DNS..." <- Are you referring to this? https://github.com/monero-project/monero/pull/8408
12:53:07 <sethforprivacy> Or is there a broader DNS issue?
13:09:35 <moneromooo> That's just papering over the issue.
13:10:34 <moneromooo> Someone was claiming a few days ago DNS is slow even when not borked. That needs fixing.
13:11:05 <moneromooo> (assuming it's within monero code)
13:12:48 <sethforprivacy> moneromooo: That was the explicit DNS issue that was noticed by myself and others, I haven't heard of any other "slow DNS" issues.
13:13:28 <sethforprivacy> That was the one that was causing 20s-1m TX generation times when you had custom DNS enabled, specifically DoH or a restrictive DNS server with blocking of other DNS servers/queries.
14:00:16 <selsta> .merge+ 8450
14:00:17 <xmr-pr> Added
14:00:32 <selsta> adding the "Fix occasional mining test failure" PR early so that we don't have spurious CI failures
15:00:14 <UkoeHB> monero1ro[m]: there is no ztm3 currently planned (maybe in a couple years...?)
15:17:39 <gingeropolous> https://www.reddit.com/r/monerosupport/comments/w4iihg/segmentation_fault_11/ , segfault macos10.11.6 and 10.13.6
15:20:21 <selsta> don't think we support 10.11 anymore
15:22:38 <ofrnxmr[m]> 10.15 minimum iirc
15:22:46 <hyc> sounds right
15:23:57 <selsta> I did test starting the binaries on older macOS versions, that did work. Will ask them for the exact crash log.
15:25:08 <ofrnxmr[m]> <w[m]> "Image_108.jpg" <- ^
15:33:41 <selsta> hyc: https://paste.debian.net/1247964/
15:33:48 <selsta> it's a randomx jit related crash, so something we should be able to fix
15:35:41 <selsta> MONERO_RANDOMX_UMASK=8 might work in the meantime
15:37:51 <hyc> yeah sounds like the runtime version check may have given a wrong answer\
15:44:37 <hyc> actually this stack trace looks suspicious, lines 74-77
15:45:00 <hyc> against line 23
15:45:27 <hyc> says it tried to access address 0xffffffffffffffff
15:46:03 <hyc> that should be the value returned from mmap() when it fails. defined as MMAP_FAILED
15:46:46 <hyc> randomx src/virtual_memory.c checks specifically for that value, and returns NULL
15:49:35 <hyc> so LargePageAllocator should have thrown an exception instead of trying to memmove anything
15:56:45 <hyc> might want to try MONERO_RANDOMX_UMASK=1 instead, to turn off largepages
15:57:06 <selsta> ok
16:05:01 <tevador> a bug was introduced in the allocator by removing this check: https://github.com/tevador/RandomX/pull/241/files#diff-e5b53929a015a60351b69d4b5183727c56182657efbbae14782785422ba8ba65L116
16:09:22 <hyc> that check was not removed, it's here https://github.com/tevador/RandomX/blob/master/src/virtual_memory.c#L225
16:11:29 <hyc> afaics anything that calls allocLargePagesMemory and gets a null returned will throw on its own
16:12:33 <hyc> oh I see, you're talking about allocMemoryPages
16:22:47 <hyc> https://github.com/tevador/RandomX/pull/250
16:23:05 <hyc> but still it seems unlikely to me that a regular alloc attempt failed
16:24:51 <sech1> I think the check should be inside one of #ifdefs
16:25:22 <sech1> because VirtualAlloc doesn't return MAP_FAILED. It can even fail to compile on Windows
16:25:34 <hyc> ah good point
16:28:58 <selsta> UMASK 8 works, currently waiting for them to test 1
16:37:24 <hyc> I don't see why this crash is OS version related, the OS version check is correct
16:37:50 <hyc> unless maybe there's some other feature we're using that is version-dependent that we haven't isolated
16:39:23 <selsta> 250 should solve the crash but it's still unclear why allocation fails in the first place?
16:43:13 <hyc> right
16:43:35 <hyc> meh. actually notthing is clear here :P
16:44:18 <hyc> but yeah, clearly the system has enough RAM
16:48:58 <tevador> one way to find out would be to check errno after the failed call
16:49:05 <tevador> probably some parameters are wrong
17:00:41 <hyc> anyone else with Intel Mac on such old OS rev around here?
17:05:56 <hyc> the only thing that seems unusual is our use of MAP_JIT but apple docs say it's supported since 10.7
17:16:27 <selsta> I have a VM with 10.11
17:16:38 <selsta> would that work?
17:16:52 <selsta> 10.11 or 10.12, don't remember
17:17:41 <selsta> UMASK=1 didn't work but I think that's expected since this isn't the large page allocator
17:24:29 <hyc> ok
17:24:41 <hyc> and yeah, seems like 10.11 is old enough to have the failure
17:31:08 <hyc> hm I should be able to set it up in a VM as well
17:34:42 <jeffro256[m]> I’ve got an macbook with 10.10
17:34:50 <jeffro256[m]> I’ll try it on there
17:38:07 <selsta> hyc: do you have an Intel Mac? M1 doesn't work with old versions
17:38:18 <selsta> if you have an idea what to test I can run it
17:38:59 <selsta> jeffro256[m]: btw, did you see the comment regarding portable_storage doc? can you remove the draft setting?
17:59:51 <selsta> .merge+ 8427
17:59:51 <xmr-pr> Added
18:30:18 <hyc> selsta no, I don't have an Intel Mac, just an M1 macbook pro
18:30:49 <hyc> but if I can install macos in an x86 VM that should be good enough to investigate these things
18:34:26 <selsta> https://github.com/sickcodes/Docker-OSX might be useful
18:43:46 <hyc> my virtualbox gets a critical error trying to boot the macosx 10.11.6 iso
18:46:20 <r4v3r23[m]> i got a bunch of sendto: Operation not permitted messages when closing monerod
18:46:21 <r4v3r23[m]> * bunch of `sendto: Operation, * not permitted` messages
18:48:42 <hyc> guess I'll try that high sierra docker img
18:53:15 <hyc> meh. that booted but then crashed
18:56:08 <selsta> r4v3r23[m]: which OS?
19:24:53 <r4v3r23[m]> <selsta> "r4v3r23: which OS?" <- linux
19:26:00 <selsta> r4v3r23[m]: did it take longer than usual to close?
19:26:37 <selsta> quite sure it's unbound again being annoying
19:37:58 <r4v3r23[m]> <selsta> "quite sure it's unbound again..." <- no its closes really fast, just noticed it last 2 times i closed monerod
21:35:16 <jeffro256[m]> > jeffro256: btw, did you see the comment regarding portable_storage doc? can you remove the draft setting?
21:35:16 <jeffro256[m]> Yeah I did, I'll remove the draft flag, I just wanted someone to review it