are mining test failures a known issue? github.com/monero-project/monero/actions/runs/2707319829

this fails occasionally on CI, like every 10 runs

Couldn't stop mining due to unknown error.

ok

<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.

sounds good

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.

binaryFate: Understood, thanks for the context! Just wanted to make sure it wasn't forgotten 🙂

thanks for following up on tasks and please make sure I do it in 3 days :)

Are there any known significant issues with 0.18?

multisig is still officially experimental/unsafe, as I'm pretty sure burner bug fix hasn't been merged

`mpnerod` is still rather spammy, when doing background mining:

2022-07-21 04:24:58.107 I background mining is enabled, but not started, waiting until start triggers... (full message at libera.ems.host/_matrix/media/r0/do…7db686b8e32ca1f5548af8ad22a4a90a160)

TrasherDK[m]: did you open a github issue for it?

Nope. I kinda left it at Moo agreed it was too verbose 😳 It's not really anything more than annoying noise. Not a bug.

monero-project/monero #8450 fixes that mining test error (it was spurious).

It also silences "not enough RAM" warning, was it an annoying warning?

For me, yes. I run on VMs.

Also, I ran into an odd failure:

In handle_accept, Exception in boosted_tcp_server<t_protocol_handler>::handle_accept: local_endpoint: Bad file descriptor

That kills connectivity to RPC (a longstanding problem).

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.

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.

I pushed an update which makes it so you can get the verbose stuff with the MINING_SILENT=0 var.

any good first issues a new dev can tackle?

new to monero*

You could go to github, look at the issues, pick something that looks simple.

I'm reading "From zero to monero 2.0" and it seems to be a good start. i

Is there a 3.0 in process?

Or use the software, find something that annoys you in particular, and fix that.

Oh, a good one: apparently DNS queries are slow even with well configured DNS. Fixing this would be nice.

👀

is there an open issue for this?

Probably, three was discussion of this a while back.

monero-project/monero #8440 seems like the wrong place to post this

^ use scam wallet = get scammed

my 2c on that one

New to GitHub as well I guess?

There is a search button

didn

t know you could search through issues

You can search through the entire repo

Can also search through PR's that need reviews or are incomplete etc

<jeffro256[m]> "multisig is still officially..." <- Burning bug fix was merged before release: monero-project/monero 02cbccc

<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.

> <@sgp:magicgrants.org> Are there any known significant issues with 0.18?

* 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.

<moneromooo> "Oh, a good one: apparently DNS..." <- Are you referring to this? monero-project/monero #8408

Or is there a broader DNS issue?

That's just papering over the issue.

Someone was claiming a few days ago DNS is slow even when not borked. That needs fixing.

(assuming it's within monero code)

moneromooo: That was the explicit DNS issue that was noticed by myself and others, I haven't heard of any other "slow DNS" issues.

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.

.merge+ 8450

Added

adding the "Fix occasional mining test failure" PR early so that we don't have spurious CI failures

monero1ro[m]: there is no ztm3 currently planned (maybe in a couple years...?)

reddit.com/r/monerosupport/comments/w4iihg/segmentation_fault_11 , segfault macos10.11.6 and 10.13.6

don't think we support 10.11 anymore

10.15 minimum iirc

sounds right

I did test starting the binaries on older macOS versions, that did work. Will ask them for the exact crash log.

<w[m]> "Image_108.jpg" <- ^

hyc: paste.debian.net/1247964

it's a randomx jit related crash, so something we should be able to fix

MONERO_RANDOMX_UMASK=8 might work in the meantime

yeah sounds like the runtime version check may have given a wrong answer\

actually this stack trace looks suspicious, lines 74-77

against line 23

says it tried to access address 0xffffffffffffffff

that should be the value returned from mmap() when it fails. defined as MMAP_FAILED

randomx src/virtual_memory.c checks specifically for that value, and returns NULL

so LargePageAllocator should have thrown an exception instead of trying to memmove anything

might want to try MONERO_RANDOMX_UMASK=1 instead, to turn off largepages

ok

a bug was introduced in the allocator by removing this check: tevador/RandomX #241/files#diff-e5b53929a015a60351b69d4b5183727c56182657efbbae14782785422ba8ba65L116

that check was not removed, it's here github.com/tevador/RandomX/blob/master/src/virtual_memory.c#L225

afaics anything that calls allocLargePagesMemory and gets a null returned will throw on its own

oh I see, you're talking about allocMemoryPages

but still it seems unlikely to me that a regular alloc attempt failed

I think the check should be inside one of #ifdefs

because VirtualAlloc doesn't return MAP_FAILED. It can even fail to compile on Windows

ah good point

UMASK 8 works, currently waiting for them to test 1

I don't see why this crash is OS version related, the OS version check is correct

unless maybe there's some other feature we're using that is version-dependent that we haven't isolated

250 should solve the crash but it's still unclear why allocation fails in the first place?

right

meh. actually notthing is clear here :P

but yeah, clearly the system has enough RAM

one way to find out would be to check errno after the failed call

probably some parameters are wrong

anyone else with Intel Mac on such old OS rev around here?

the only thing that seems unusual is our use of MAP_JIT but apple docs say it's supported since 10.7

I have a VM with 10.11

would that work?

10.11 or 10.12, don't remember

UMASK=1 didn't work but I think that's expected since this isn't the large page allocator

ok

and yeah, seems like 10.11 is old enough to have the failure

hm I should be able to set it up in a VM as well

I’ve got an macbook with 10.10

I’ll try it on there

hyc: do you have an Intel Mac? M1 doesn't work with old versions

if you have an idea what to test I can run it

jeffro256[m]: btw, did you see the comment regarding portable_storage doc? can you remove the draft setting?

.merge+ 8427

Added

selsta no, I don't have an Intel Mac, just an M1 macbook pro

but if I can install macos in an x86 VM that should be good enough to investigate these things

github.com/sickcodes/Docker-OSX might be useful

my virtualbox gets a critical error trying to boot the macosx 10.11.6 iso

i got a bunch of sendto: Operation not permitted messages when closing monerod

* bunch of `sendto: Operation, * not permitted` messages

guess I'll try that high sierra docker img

meh. that booted but then crashed

r4v3r23[m]: which OS?

<selsta> "r4v3r23: which OS?" <- linux

r4v3r23[m]: did it take longer than usual to close?

quite sure it's unbound again being annoying

<selsta> "quite sure it's unbound again..." <- no its closes really fast, just noticed it last 2 times i closed monerod

> jeffro256: btw, did you see the comment regarding portable_storage doc? can you remove the draft setting?

Yeah I did, I'll remove the draft flag, I just wanted someone to review it