<t​obtoht:monero.social> sech1: can you try this build. release-v0.18 + boost 1.84: github.com/tobtoht/monero/actions/runs/13380438243

sure

F*CK wrong alt

<v​tnerd:monero.social> Damn, and I removed some sketchy casting that was in existing code too. What's left should've been straightforward

<0​xfffc:monero.social> no crash here: github.com/tobtoht/monero/actions/runs/13380438243

<t​obtoht:monero.social> 0xfffc: can you also test this one to rule out a compiler bug: github.com/tobtoht/monero/actions/runs/13380562426

tobtoht github.com/tobtoht/monero/actions/runs/13380438243 doesn't crash for me

github.com/tobtoht/monero/actions/runs/13380562426 crashes

so it's probably a boost bug, not a compiler bug

or maybe it's still a compiler bug that's present in both compiler versions

sech1: did you check if the issue is also present in gitian on release-v0.18? it uses an older version gcc

<0​xfffc:monero.social> tobtoht: github.com/tobtoht/monero/actions/runs/13380562426 crashed

I'll restart the gitian build now

can you try release-v0.18 + boost 1.67: github.com/tobtoht/monero/actions/runs/13385369440

<0​xfffc:monero.social> tobtoht: github.com/tobtoht/monero/actions/runs/13385369440 no crash, syncing without issue

gitian build crashes

can you share logs?

It's just a silent crash, nothing in the logs even at level 2

github.com/tobtoht/monero/actions/runs/13385369440 crashed for me

sech1: release-v0.18 + revert 9800 sanity check: github.com/tobtoht/monero/actions/runs/13386066774

no crash so far (synced first 50k blocks 2 times)

3 times, no crash

ok, good

i have release-v0.18 gitian builds running in ci now

"gitian build crashes" <- oh, haven't had enough sleep. i interpreted that as gitian builds failing

So it's a combination of boost and some GCC versions that crashes (GCC 14.2.0 works fine with this boost version)

Either some bug in boost, or too complex code for older GCC versions (bug in GCC)

the msys2 build? it doesn't use boost 1.66

oh

What does it use?

1.87.0

so with crashes on three versions of gcc i think this is a boost bug

i'm not sure how much farther we can update boost on release without breaking gitian builds. and this might introduce other issues. a revert seems like the safest option for now

I took a quick glance at #9800

I has "const auto results = resolver.resolve(...); ... results.begin()->..." pattern in several places

without checking that results is not empty

not a safe approach

*It has

It does have "if(results.empty())" checks in a few other places

Very concerning

This is in contrib/epee/include/net/abstract_tcp_server2.inl

"m_endpoint = *resolver.resolve(udp::v4(), m_device_host, std::to_string(m_device_port)).begin();"

That's very optimistic :D

tobtoht_ but latest master branch didn't crash for me, so it's some combination of boost + GCC versions + surrounding code that crashes. Must be a compiler bug, or an undefined behavior.

master uses boost 1.84

that explains it

Boost is the culprit :D

vtnerd Can you add the checks that "resolver.resolve" returns non-empty list of results everywhere you call it? 9800 looks inconsistent in this department.

<0​xfffc:monero.social> boost is abomination!

<0​xfffc:monero.social> CMake used to be abomination. But it is better these days!

<s​yntheticbird:monero.social> so...

<s​yntheticbird:monero.social> does anyone have any idea why levin signature is categorized as "Bender's nightmare" ?

<s​yntheticbird:monero.social> I tried to search but Futurama is a big series, hard to find which episode this is referring to

<s​yntheticbird:monero.social> cc luigi1111

that's a good one

sech1: can you try release-v0.18 + boost 1.69: github.com/tobtoht/monero/actions/runs/13390257229

no crash so far (3 times x 50k first blocks)

ok great

I will test more

ty

Hmm idk Syntheticbird

2025-02-18 12:42:23.547 6248 INFO global src/daemon/main.cpp:309 Monero 'Fluorine Fermi' (v0.18.4.0-af84f7cc6)

just to confirm it's that commit

yep

"i thought i saw a 2"

<o​frnxmr:xmr.mx> What

monero-project/monero #9806 is this issue complete AI hallucination?

luigi1111: can you block them from org ^?

they posted some incomprehensible image on a pr earlier, then deleted it. might be a bot?

yes seems to be a troll who opens nonsensical issues and PR

Can tob do that? I'm not in office

oh let me check

block user menu item doesn't appear for me

wow, first time I see such an elaborate attempt

"xmrrpcunsafe" is nowhere to be found in Monero/Monero GUI code, and it even mutates into "zrpcunsafe" on one line

sech1: here is a gitian build for that pr: github.com/tobtoht/monero/actions/runs/13390257256

no crash

perfect

<w​oodser:monero.social> happy to run more tests when there's a fix for PR 9460 (it works with `--max-connections-per-ip 10` but not by default)

<o​frnxmr:xmr.mx> I think max connections might be intended behavior

<o​frnxmr:xmr.mx> Its 1 by default, so it shouldnt have allowed incoming connection from the same ip as outgoing to begin with (but it was, pre 9460). Seems like 9460 fixed that "bug"

<o​frnxmr:xmr.mx> Running a private testnet should require increasing max-connections-per-ip to allow 127.0.0.1 to have multiple in/out connections from the same ip

<w​oodser:monero.social> ah ok, so people shouldn't run into that problem in the wild. I'll update scripts to use that flag

<o​frnxmr:xmr.mx> vtnerd does this sound right?

<o​frnxmr:xmr.mx> I dont think there is any exceptions for localhost, so i'm surprised it ever worked before :/

<v​tnerd:monero.social> sech1: I recall verifying the presence of `.empty()` checks when using an ASIO resolver. Maybe I missed one

<v​tnerd:monero.social> oops, definitely did not add checks in abstract_tcp_server2.inl

<v​tnerd:monero.social> this should’ve been a problem previously though, it doesn’t look like i removed in existing checks (just copied missing checks behavior)

<v​tnerd:monero.social> yeah there’s a `.empty()` check in the one place that definitely needs it, and some non-checks in the init code (which may be the culprit, but looking unlikely)

<v​tnerd:monero.social> I’m busy over the next two days with things, but might be able to sneak in a fix if someone deems it necessary

<v​tnerd:monero.social> I’m a bit surprised we concluded it was Boost - do we even know why at this point?

<v​tnerd:monero.social> and [@ofrnxmr:xmr.mx](https://matrix.to/#/@ofrnxmr:xmr.mx)yes, the daemon should've never allowed more than 1 incoming p2p connection per ip

Reverting #9800 fixes the crash, changing Boost version also fixes the crash. Changing compiler version doesn't fix the crash

vtnerd yes, I found several missing checks in abstract_tcp_server2.inl and constructions like "*resolver.resolve(udp::v4(), m_device_host, std::to_string(m_device_port)).begin();" in other files

vtnerd: there are a few suspicious fixes between boost asio 1.68 and 1.69, tho not sure if related

there were no changes between boost asio 1.67 and 1.68 and 1.67 still had the crash

<v​tnerd:monero.social> oh yikes!

<v​tnerd:monero.social> yeah the code relies on `resolve.empty()` in a few places.

<v​tnerd:monero.social> what terrible bug to sneak into ASIO

<v​tnerd:monero.social> we could change from `.empty()` to a comparison against a default iterator in a few places

<v​tnerd:monero.social> the other option is to remove the `boost::system::error_code` argument to `resolve(…)`. The documentation says a successful call to resolve always has non-empty results

<v​tnerd:monero.social> sech1: The documentation stated that the result was non-empty if no errors. I’m not sure if no results found is considered an error though

tobtoht_ yeah, the crash I had was a null pointer dereference when I tried to debug it

<v​tnerd:monero.social> The .empty() check would explode in those Boost versions though

How does it return an error? Through an exception?

Then it should be wrapped in the try...catch block

<v​tnerd:monero.social> Yes, those sections are

<v​tnerd:monero.social> the only place I’m seeing no explicit `iterator == end_iterator` or `results.empty()` checks are in `abstract_tcp_server2.inl`

<v​tnerd:monero.social> and those are wrapped with catch blocks. We may want to add an explicit check since the documentation isn’t 100%, otoh this behavior was actually unchanged by 8400

<o​frnxmr:xmr.mx> Bitcoin has a configurable option for the min fee that the node will relay. I dont think monero has a setting for this, but do we have a minimum? Or can custom wallets send 0 fee tx that will be relayed and confirmed?

0 fee is rejected by node in monero-core

custom node can accept + mine to block a 0fee

<j​effro256:monero.social> There is a minimum fee per weight value calculated by the daemon as a function of previous blocks, and for a new transaction to pass relay rules, the tx's fee must be greater than that value multiplied by its weight

<j​effro256:monero.social> It's only a part of relay rules, not consensus

<j​effro256:monero.social> github.com/monero-project/monero/bl…ryptonote_core/blockchain.cpp#L3646

<o​frnxmr:xmr.mx> Ty sir

<o​frnxmr:xmr.mx> sirs*

<s​yntheticbird:monero.social> OGs

<s​yntheticbird:monero.social> who is Antonio Juarez ?

<s​yntheticbird:monero.social> when did he disappear?

<s​yntheticbird:monero.social> is he still alive?

<s​yntheticbird:monero.social> cc selsta

afaik some made up name from bytecoin time

<s​yntheticbird:monero.social> ouch, unlikely to find him again then

<o​frnxmr:xmr.mx> ask zano

<s​yntheticbird:monero.social> doedl?

<o​frnxmr:xmr.mx> nah zoidbergn

<s​yntheticbird:monero.social> is he part of zano?

<s​yntheticbird:monero.social> funny

<s​yntheticbird:monero.social> you made me laugh

<s​yntheticbird:monero.social> good job

<o​frnxmr:xmr.mx> Crypton zoidberg is guy who says he developed bytecoin

<o​frnxmr:xmr.mx> I'm not joking

<s​yntheticbird:monero.social> lmao this cannot be a coincidence

<s​yntheticbird:monero.social> thx, i'll try to find him

<s​yntheticbird:monero.social> I was on the verge of making a reddit post

<o​frnxmr:xmr.mx> There was also a long post on bitcointalk about this

<s​yntheticbird:monero.social> really?

<s​yntheticbird:monero.social> really? (he responded)