is there anything i need to do with my PR or is everything ok?

are there any rough estimations of when CLI and especially GUI are being tagged for release? I'm asking because I want to make a call-for-translators shortly after tagging so they can work on it. Plenty of languages require few strings to be fully translated

netrik182: The call for translators need to be done before tagging. After a release is tagged nothing is going in

Hmm, I don't think 17.3 is large enough to require new translations

.merge+ 8031 8032

Added

alright, will do before. thanks erciccione

my question is still somewhat relevant though

You can decide if you want to update the strings now and then call for translators or wait until most of the changes are in and then call for translators. With the former translators have more time but can be that the language files will need to be refreshed more than once. With the latter you have translators working on mostly ready language files, but have less time and can be that there will be changes in the strings that will result in that

string showing in english in all languages.

my suggestion is too coordinate with the GUI people to make an estimate of how many string changes are planned. If it's not many, i would go for the second option.

so i would put pressure on the GUI devs for having all string changes in as soon as possible and right after those are merged call for translators

^ this is assuming we are close to a GUI release

i also used to implore the GUI devs to not merge any string change after the language files have been refreshed and you called for translators, unless strictly necessary. That helps :)

atomfried[m]: please squash, then it should be ready to merge

these 3 PRs need a review before we can put out a release: 8023 8021 7997

they are all simple so hopefully someone can take a look

[...] 7997 [...] simple... :D

Or was that a typo in the PR number ?

these are all PRs that were already merged, so simple in that sense :P

but it might be a bit of work to compare them

were already merged, or about to be merged

The list seems to have a numbr of non bug fix commits. Intended for the release branch ?

afaik the only one is the --proxy command, where we decide to include as the "major" feature for v0.17.3.0

otherwise it should be bug fixes

I keep getting std::runtime_error's from monerod, backtracing to librandomx, and I think it even crashed my kernel twice (!?) - any ideas?

Well, I see the C++14 ones, some logging stuff, more seed nodes (those will be small though).

Get a kernel that doesn't crash when userland misbehaves :)

Anyway, be more precise. Is anything not working beyond your kernel ?

If this is just about log spam, you can start with: --log-level 0,*stack*:FATAL

Well it's a virtual server, EPYC 7something, 16 cores out of 48, everything works fine

It crashed yesterday, totally unresponsive, I reboot it.... crashed again a few hours later. Monerod log is full of those exceptions, everything else is fine. Had a three month uptime before I started running monerod - the debian testing version

I've compiled a fresh version but I wanted to get advice before switching to it

Well, my advice would be check whether it's not going into some swapstorm. I assume you don't have some panic output etc in the kernel logs ?

Nothing in the logs... the server has 64 GB ram, I don't know if swap is enabled I'll check

I was wondering if it could be some kind of betwork attack

64 ought to be just fine.

s/betwork/network/

Could be. You never know. The world is full of assholes.

It's happened before :)

Through monerod?

Well I wouldn't know. It's *possible*, but I dunno whether that's what happened.

Kernels will usually kill any memory hungry process though when they need space.

Sure but the whole thing went poof.

Are there any hardening options I can enable while compiling monerod?

No. Though you should ensure you firewall everything but 18080 (P2P port).

Ok I'll check. Maybe I should tcpdump the traffic to another machine until it crashes

I added the C++14 patch because I thought it would be annoying when writing something for master and then having to change it for release branch just because a different CPP version is used.

OK

but others might have different opinions but yes it's not a bug fix

Oh. Not really hardening, but --limit-up and --limit-down I guess. And maybe --out-peers and --in-peers.

They limit network traffic amount/time and nubmer of p2p peers, resp.

max of these.

selsta : its been audited too, right? so its most likely ready, but I will finish looking over it today

Test

<monerobull> test

Test2

<monerobull> discord matrix bridge works for this channel now

monerobull: please make the bridge read-only for this channel and #monero-research-lab:matrix.org.

Sure

Thanks.

F

.merge+ 8021 8037 8023

Added

sech1: you around? have you run core_tests on a recent arm64 build?

getting a SEGV on master paste.debian.net/1217977

it's a piece of RandomX code calling into unmapped memory

you can see that the calling address on line #22 of the paste resides in executable anonymous memory shown at line #68

that and line #70 are the only executable anonymous memory. everything else is from executable files/sharedlibs

I've added the info to PR#8031, following up mj-xmr[m]'s comment. but this crash occurs independently of this PR, prob should be its own issue.

Hello everyone ,... (full message at libera.ems.host/_matrix/media/r0/do…9e6922e5fd1c4d7f45a209d2461080ed061)

hyc, does it fail with disabled jit for randomx ?