<0​xfffc:matrix.org> moneromoooo: monero-project/monero #8912#issuecomment-1730512431

<0​xfffc:matrix.org> It was because someone in one of his commits was not taking care of `current_function_decl` variable. Which should never be null, unless before compilations or after compilation of a functions finishes.

<0​xfffc:matrix.org> Good news is it has been merged to releases/gcc-12 and releases/gcc-13 already. So it should work gcc.gnu.org/git/?p=gcc.git;a=commit…23ccbb3bb16a6569256bb6500c554d4c333

<0​xfffc:matrix.org> That is why my 13 was able to build it.

nice! regarding pending review, I assume this would be added to every PR that is ready and needs a review and the label would be removed again after it got reviewed? or do projects use a different workflow?

<0​xfffc:matrix.org> selsta That would be huge help in my opinion. Basically devs can go through PRs with “pending review” label, and reviewing them. Would be much smoother IMHO

<0​xfffc:matrix.org> Basically as you described. Once PR is ready “pending review”, once it reviewed, it can remove the label. (I believe some projects require multiple reviewer and would only remove tag/label once they have certain number of reviewer)

<j​effro256:monero.social> @selsta I fixed the watch-only storing bug

<j​effro256:monero.social> PR #8998

Did my daemon just destroy its blockchain file somehow syncing mainnet over about 1 month?

2023-09-22 07:05:22.849 E Exception at [portable_storage::load_from_binary], what=duplicate key: support_flags

No, it's someone running a broken node

I get these too

Oh the joy of permissionless networks :)

Thanks sech1

Someone maybe sending around broken / malformed transactions?

probably

rbrunner: i speculated before that it may be a nevocoin node, some experimentation and tcpdumping may be in order :)

Hmm yeah who knows. Not fully sure, but I think I saw in their source that they configured default ports different from Monero

jeffro256: thank you!

.merge+ 8998 8999

Added

should we move the `E Exception at [portable_storage::load_from_binary], what=duplicate key: support_flags` message to a different log level? it's quite noisy

in the past I saw it a couple times but now someone seems to run a node with this invalid code constantly

selsta, I think its more than one actually

I tried to block it but keeps coming up

Prob better to add:

#define MONERO_DEFAULT_LOG_CATEGORY

#define MONERO_DEFAULT_LOG_CATEGORY "serialization"

at the top of contrib/epee/include/storages/portable_storage_from_bin.h

Possibly other similar headers that use CHECK* macros.

er, the first #define is meant to be #undef

And you may want to trap this at some high enough level to drop broken nodes that do this. It'll help whoever this is notice their code is broken and fix it.

would be nice if the node auto blocked those after a few errors thrown or smth

<j​effro256:monero.social> I think this is a good idea. Anyone can trigger that error remotely with no effort as fast as they want

opened it here: monero-project/monero #9000

the auto ban change can be done later in a different release

<j​berman:matrix.org> I suspect it's a bug on preliminary read-through, I think auto ban would be a bit hasty. I've been looking into it a bit on and off

<j​berman:matrix.org> log level 1, grep `COMMAND_REQUEST_SUPPORT_FLAGS invoke failed` you'll see it for a range of different ip's. looks potentially like something being mishandled on handshake

we didn't put out an update in months, I doubt it's in our code

maybe some spy nodes that are misconfigured :D