00:04:00 <m-relay> <0​xfffc:matrix.org> moneromoooo:  https://github.com/monero-project/monero/issues/8912#issuecomment-1730512431
00:04:58 <m-relay> <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.
00:06:07 <m-relay> <0​xfffc:matrix.org> Good news is it has been merged to releases/gcc-12 and releases/gcc-13 already. So it should work https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0d7e5f90597167c36c7816f5bcf689472e8b1940;hp=b16f123ccbb3bb16a6569256bb6500c554d4c333
00:06:08 <m-relay> <0​xfffc:matrix.org> That is why my 13 was able to build it.
00:12:21 <selsta> 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?
00:16:50 <m-relay> <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
00:27:09 <m-relay> <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)
03:44:56 <m-relay> <j​effro256:monero.social> @selsta I fixed the watch-only storing bug
03:45:07 <m-relay> <j​effro256:monero.social> PR #8998
03:45:11 -xmr-pr- jeffro256 opened pull request #8998: wallet: store watch-only wallet correctly when `change_password()` is ...
03:45:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8998
07:06:19 <rbrunner> Did my daemon just destroy its blockchain file somehow syncing mainnet over about 1 month?
07:06:20 <rbrunner> 2023-09-22 07:05:22.849	E Exception at [portable_storage::load_from_binary], what=duplicate key: support_flags
07:07:06 <sech1> No, it's someone running a broken node
07:07:09 <sech1> I get these too
07:07:35 <rbrunner> Oh the joy of permissionless networks :)
07:07:56 <rbrunner> Thanks sech1
07:08:50 <rbrunner> Someone maybe sending around broken / malformed transactions?
07:10:52 <sech1> probably
07:52:36 <elucidator> rbrunner: i speculated before that it may be a nevocoin node, some experimentation and tcpdumping may be in order :)
08:09:29 <rbrunner> Hmm yeah who knows. Not fully sure, but I think I saw in their source that they configured default ports different from Monero
09:47:39 <selsta> jeffro256: thank you!
14:30:11 -xmr-pr- jeffro256 opened pull request #8999: wallet: store watch-only wallet correctly when `change_password()` is ...
14:30:11 -xmr-pr- > https://github.com/monero-project/monero/pull/8999
15:14:20 <selsta> .merge+ 8998 8999
15:14:20 <xmr-pr> Added
15:17:07 <selsta> 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
15:19:18 <selsta> in the past I saw it a couple times but now someone seems to run a node with this invalid code constantly
15:19:43 <kico> selsta, I think its more than one actually
15:20:08 <kico> I tried to block it but keeps coming up
15:32:55 <moneromooo> Prob better to add:
15:32:56 <moneromooo> #define MONERO_DEFAULT_LOG_CATEGORY
15:32:56 <moneromooo> #define MONERO_DEFAULT_LOG_CATEGORY "serialization"
15:33:08 <moneromooo> at the top of contrib/epee/include/storages/portable_storage_from_bin.h
15:33:35 <moneromooo> Possibly other similar headers that use CHECK* macros.
15:33:52 <moneromooo> er, the first #define is meant to be #undef
15:34:56 <moneromooo> 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.
15:37:44 <kico> would be nice if the node auto blocked those after a few errors thrown or smth
16:10:07 <m-relay> <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
17:07:56 <selsta> opened it here: https://github.com/monero-project/monero/pull/9000
17:08:18 <selsta> the auto ban change can be done later in a different release
17:15:11 -xmr-pr- selsta opened pull request #9001: storages: change error log category to serialization [release-v0.18]
17:15:11 -xmr-pr- > https://github.com/monero-project/monero/pull/9001
17:15:11 -xmr-pr- selsta opened pull request #9000: storages: change error log category to serialization
17:15:11 -xmr-pr- > https://github.com/monero-project/monero/pull/9000
21:47:48 <m-relay> <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
21:54:34 <m-relay> <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
22:07:47 <selsta> we didn't put out an update in months, I doubt it's in our code
22:07:55 <selsta> maybe some spy nodes that are misconfigured :D