06:23:30 <jeffro256> @hyc: I have a strange issue where a call to `mdb_env_open()` works inside `cryptonote::BlockchainLMDB::open()` when I run a program (`xmrblocks`) regularly. It also works fine with I run that program inside a debugger (`gdb`), but it fails when I run that program in `valgrind`. When running with `valgrind`, `mdb_env_open()` returns EINVAL. 
06:24:05 <jeffro256> I'm having trouble debugging since I can't reproduce it when I run with a debugger. Do you have any idea what could be going on?
08:45:05 -xmr-pr- tobtoht opened pull request #9801: guix: add rust
08:45:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9801
09:56:49 <selsta> .merge+ 9403 9428
09:56:49 <xmr-pr> Added
15:28:46 <sech1> I have trouble building the release branch in MSYS2, I get linking errors: https://paste.debian.net/hidden/ac3578ef/
15:29:01 <sech1> If anyone can recognize them, maybe you know how to fix it quicklyy
15:30:53 <sech1> Some conflict between libunwind.a and libgcc_eh.a
15:36:57 <selsta> sech1: is this with updating all msys2 packages?
15:37:07 <selsta> release-v0.18 msys2 ci was successful yesterday https://github.com/monero-project/monero/actions/runs/13352067922/job/37289871151
15:37:27 <sech1> Yes, I did "pacman -Syuu" several times before building
15:38:02 <sech1> Manually disabling libunwind in CMakeLists.txt fixed the issue, but now I won't get callstacks if something happens
15:38:45 <selsta> it's possible we don't have libunwind installed with CI builds
15:39:19 <selsta> .merge+ 9439 9438
15:39:19 <xmr-pr> Added
15:41:03 <sech1> yeah, my MSYS2 installation is several years old and I've installed and built a lot of different stuff there
15:42:54 <sech1> wtf, the binary I build just nuked my blockchain and started downloading it from 0
15:43:00 <sech1> *built
15:44:24 <sech1> stopped it, started again and it started from 0 again (nuking the previous data.mdb)
15:51:13 <selsta> i don't think we have any code that can delete the data.mdb
15:53:35 <selsta> i've done testing on linux and macOS and did not see such a behaviour, but I don't have a windows system to confirm
15:54:28 <sech1> I can reproduce it consistently, it just refuses to load data.mdb that is there and starts from 0
15:54:44 <sech1> log level 3 didn't clear up things for me
15:55:36 <sech1> I think my binary build is broken somehow, I'll revert to v0.18.3.4 for now
15:55:50 <sech1> I'll build the gitian build later to see if it has the same issue
15:55:52 <m-relay> <o​frnxmr:xmr.mx> 👀
16:10:51 <m-relay> <j​effro256:monero.social> sech1: what does running `mdb_stat -rr <MONERO DATA DIR>/lmdb` return ?
16:11:14 <sech1> Where do I get mdb_stat?
16:12:03 <m-relay> <j​effro256:monero.social> You can build mdb_stat from the external/db_drivers/liblmdb Makefile
16:12:33 <sech1> I reverted back to v0.18.3.4 and it's syncing again now. It was a perfectly fine lmdb file before I started all this (I was stopping/starting v0.18.3.4 monerod many times)
16:13:11 <sech1> So when it nuked the blockchain first time, it wasn't corrupt 100%
16:13:47 <sech1> I'm building gitian build of the latest release-v0.18 branch, I'll try it when it finishes
16:14:28 <m-relay> <j​effro256:monero.social> Someone else was posting that running the latest release-v0.18 caused crashes from stale readers
16:14:45 <m-relay> <j​effro256:monero.social> That's what I've been attempting to debug for the last 2 days
16:15:39 <m-relay> <j​effro256:monero.social> I think it's related to the xmrblocks block explorer, but I'm not quite sure ... At any rate, it appears to work with v0.18.3.4, but not with latest release-v0.18
16:15:42 <m-relay> <o​frnxmr:xmr.mx> Jeffro, windows the issue youre looking at too?
16:16:32 <m-relay> <o​frnxmr:xmr.mx> If using release branch with xmrblocks (onion explorer) it doesnt work
16:17:11 <m-relay> <j​effro256:monero.social> Nope on Linux
16:17:21 <m-relay> <j​effro256:monero.social> How doesn't it work in your case?
16:18:02 <sech1> jeffro256 you could try to reproduce it - just build in a Windows VM using MSYS2 and the official MSYS2 build instructions. You might get a coupe of compiler and linker errors, but they're easy to fix - ask me if you get them.
16:19:26 <m-relay> <o​frnxmr:xmr.mx> onion explorer devel branch pairs withonero master
16:19:39 <m-relay> <o​frnxmr:xmr.mx> Their master branch pairs with monero latest release tag
16:20:11 <m-relay> <o​frnxmr:xmr.mx> Their devel branch already has c++17 https://github.com/moneroexamples/onion-monero-blockchain-explorer/pull/325
16:20:12 <m-relay> <o​frnxmr:xmr.mx> https://github.com/moneroexamples/onion-monero-blockchain-explorer/commit/5285f9ca39d406b6de77fd9b60239ce4e5b0b4d0
16:22:10 <m-relay> <o​frnxmr:xmr.mx> Building onion master against monero release-v0.18 requires this pr https://github.com/moneroexamples/onion-monero-blockchain-explorer/pull/320
16:24:26 <selsta> sech1: https://github.com/monero-project/monero/actions/runs/13374316072 this has a windows build artifact for release-v0.18
16:26:38 <sech1> selsta yeap, same behavior. It nuked blockchain again and started from 0
16:27:05 <sech1> at least it's 100% reproducible, should be easy to debug
16:28:57 <sech1> and it's unstable, crashes during sync
16:29:28 <selsta> will go through all commits merged since the last release and check if anything touches the database
16:30:05 -xmr-pr- tobtoht opened pull request #9802: common: add missing iomanip include
16:30:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9802
16:31:49 <m-relay> <j​effro256:monero.social> PRs https://github.com/monero-project/monero/pull/9689 and https://github.com/monero-project/monero/pull/9622 touch the cryptonote_core/blockchain.cpp  since v0.18.3.4
16:32:17 <sech1> I thought at first that this bug happened because of my setup (monerod as a Windows service), but no. Running straight from command line without parameters results in the same. Blockchain nuked and it starts from 0
16:32:24 <sech1> and then even crashes during sync
16:32:39 <m-relay> <j​effro256:monero.social> Is there a crash message?
16:32:46 <selsta> .merge+ 9802 9803
16:32:46 <xmr-pr> Added
16:32:56 <sech1> No, it just exits
16:32:59 <sech1> with no message
16:35:05 <m-relay> <j​effro256:monero.social> PRs https://github.com/monero-project/monero/pull/9705 and https://github.com/monero-project/monero/pull/9702 touch cryptonote_db/ folder since v0.18.3.4
16:35:07 <sech1> log level 2 doesn't show anything interesting
16:35:29 <m-relay> <j​effro256:monero.social> Both of the latter are Windows related
16:36:19 <sech1> I didn't see messages from 9702
16:36:24 <sech1> 9705 looks sus
16:36:49 <sech1> boost::filesystem::file_size might not work at all
16:37:11 <m-relay> <j​effro256:monero.social> Should be commit 6392361d62d47b74977e1b4f31a6db48a706f083 on the release-v0.18 branch
16:37:34 <sech1> but that commit doesn't explain why it crashes during sync
16:38:33 <texxy> hi guys
16:38:42 <m-relay> <j​effro256:monero.social> Oh sorry I see what you're saying. I thought you meant that you didn't see evidence of that PR being in the branch
16:39:21 <texxy> i am new to crypto
16:39:29 <texxy> how does xmr prevent replay attacks
16:39:43 <sech1> So the latest release-v0.18 can't sync on Windows (crash) and can't load the existing database (overwriting it in the process)
16:40:09 <texxy> my bad i am in #monero now
16:41:15 <tobtoht_> sech1: reproducible with gitian?
16:42:00 <sech1> gitian still building and will take several hours because I nuked gitian files before to free space
16:43:28 <m-relay> <0​xfffc:monero.social> Give me a little bit of time ( 2 h) . I will compile it on windows and debug it. 
16:43:28 <m-relay> <0​xfffc:monero.social> Possible?
16:43:53 <m-relay> <o​frnxmr:xmr.mx> You can test it here https://github.com/monero-project/monero/actions/runs/13374316072
16:43:58 <m-relay> <o​frnxmr:xmr.mx> Backup your blockchain first
16:46:25 <selsta> tobtoht_: it's reproducible with depends builds so likely also gitian
16:52:45 <tobtoht_> yep can reproduce with depends
16:53:04 <selsta> it should be easy to git bisect the issue
17:00:36 <m-relay> <o​frnxmr:xmr.mx> If you have a windows box 🥸
17:03:43 <m-relay> <j​effro256:monero.social> sech1: is is reproducible with `--offline`?
17:04:34 <sech1> But it doesn't sync with --offline? If you're talking about blockchain nuking, then probably yes because it happens very early during startup
17:05:02 <sech1> I can't test now, syncing again with v0.18.3.4. I need to restore my node.
17:21:18 <tobtoht_> my bisect came up with this: https://github.com/monero-project/monero/pull/9702
17:21:41 <tobtoht_> will revert locally to double-check
17:22:56 <m-relay> <j​effro256:monero.social> Perhaps the `CreateFileW` call?
17:45:37 <m-relay> <j​effro256:monero.social> I think I found it
17:45:41 <m-relay> <j​effro256:monero.social> Will PR in a couple minuts
17:51:37 <selsta> jeffro256: if you touch that code can you also fix the `compressend` typo?
17:52:32 <m-relay> <j​effro256:monero.social> Of course
17:52:47 <sech1> boost::filesystem::ofstream(datafile).close(); // touch the file to ensure it exists
17:52:48 <sech1> lol
17:52:53 <sech1> "touch" by rewriting it
17:53:36 <sech1> yeah, that explains why it gets nuked
17:53:46 <sech1> but it doesn't explain random crashes during sync
17:54:32 <m-relay> <o​frnxmr:xmr.mx> Maybe it doesnt like to be touched .. ptsd
17:56:23 <m-relay> <j​effro256:monero.social> Yup
17:56:46 <m-relay> <j​effro256:monero.social> `boost::filesystem::ofstream` always truncates by default
17:56:58 <sech1> I think that line is not needed at all
17:57:11 <sech1> "data.mdb" will be created elsewhere when it's needed
17:58:31 <jeffro256> https://github.com/monero-project/monero/pull/9804/files
17:59:03 <jeffro256> It will eventually, but I think this is the right spot to create it if it doesn't already exist because we otherwise we would skip the NTFS compression check if it's a first-time setup 
17:59:30 <jeffro256> It would eventually be caught on a second run, but it might cause failures that first run 
18:00:05 -xmr-pr- jeffro256 opened pull request #9804: BlockchainLMDB: fix data.mdb nuking on Windows
18:00:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9804
18:04:40 <sech1> yeah
18:10:21 <tobtoht_> jeffro256: also against release
18:10:48 <m-relay> <w​oodser:monero.social> I do see some difference in behavior with the current release-v0.18 branch, where published transactions are not being immediately mined? this is on my local testnet. don't know if there were any changes related to dandelion, etc which could affect behavior of being mined on a local network?
18:14:16 <m-relay> <o​frnxmr:xmr.mx> wdym by not immediately mined? What miner are you using?
18:15:05 -xmr-pr- jeffro256 opened pull request #9805: BlockchainLMDB: fix data.mdb nuking on Windows [RELEASE]
18:15:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9805
18:16:33 <m-relay> <o​frnxmr:xmr.mx> if youre using monerod to mine, and the tx is in the txpool of the monerod that mined the block, that that would be an issue. 
18:16:34 <m-relay> <o​frnxmr:xmr.mx> if youre using xmrig, then there is a 15 second job timeout by default
18:17:29 <m-relay> <w​oodser:monero.social> just using monerod to mine, and yeah, the tx isn't being confirmed when blocks are mined
18:18:51 <m-relay> <o​frnxmr:xmr.mx> Reproducibly?
18:19:33 <selsta> .merge+ 9804 9805
18:19:33 <xmr-pr> Added
18:20:04 <m-relay> <w​oodser:monero.social> reproducibly in haveno tests when the payout is made, yes
18:20:35 <m-relay> <w​oodser:monero.social> I saw it a few days ago, switched back to earlier binaries and had no problems. just tried the latest release-v0.18 branch and same issue with the payout tx not being mined in the expected blocks
18:21:13 <selsta> woodser: can you test if you can reproduce the issue with 9460 reverted?
18:21:22 <m-relay> <w​oodser:monero.social> yes
18:26:16 <m-relay> <w​oodser:monero.social> there are merge conflicts reverting that commit from the release-v0.18 branch which I'm not sure how to resolve, if anyone can point me to a commit to test?
18:31:16 <ofrnxmr> You can checkout 1 commit before it and test :P
18:31:26 <m-relay> <w​oodser:monero.social> sure
18:36:08 <m-relay> <o​frnxmr:xmr.mx> e488bc838a73f238fb31084dad344350c005654e
18:41:35 <selsta> 9460 caused sporadic issues with the p2p functional test but we thought it was related to the test itself being buggy https://github.com/monero-project/monero/issues/9755
18:41:48 <selsta> so it is my best guess for the issue you are seeing woodser
18:55:19 <m-relay> <w​oodser:monero.social> e488bc is working fine in my tests
18:59:50 <selsta> how easy is it to run the haveno tests?
19:50:10 <m-relay> <o​frnxmr:xmr.mx> woodser
19:51:26 <m-relay> <p​reland:monero.social> From my experience, it is anywhere from very easy to very difficult
19:51:38 <m-relay> <p​reland:monero.social> The only way to find out which one it’ll be is to try lol
19:52:39 <m-relay> <s​yntheticbird:monero.social> Elected most insightful insight of 2025 🏆️
19:54:44 <m-relay> <p​reland:monero.social> 😂
19:55:18 <m-relay> <p​reland:monero.social> Actually I’m just going to say that it’s incredibly difficult and it will be a challenge 
19:55:20 <m-relay> <p​reland:monero.social> That way when they try it, it’ll logically work perfectly with no issues
20:09:43 <selsta> woodser: can you also test commit 00e582a2b1bc6872dd8bddb31bd95bab79185ce6 to make sure it is 9460?
20:14:55 <m-relay> <w​oodser:monero.social> yep testing
20:17:49 <sech1> I'm testing https://github.com/monero-project/monero/commit/0232839913b13cf0ab0bb7ad25fff0c05f37d2fe (the latest from release-v0.18 branch). It doesn't delete the DB anymore, but it still crashes when syncing (and quickly).
20:19:06 <m-relay> <o​frnxmr:xmr.mx> No log for the crash?
20:21:51 <sech1> No
20:21:58 <sech1> Exception thrown at 0x0000000000DA3930 in monerod.exe: 0xC0000005: Access violation reading location 0x0000000000000000.
20:22:02 <sech1> That's all I have
20:22:16 <sech1> mov         rdx,qword ptr [rax]
20:22:17 <sech1> rax is 0
20:24:25 <sech1> I'll try to build and run under gdb, but it never worked for me on Windows
20:25:59 <sech1> huh, gdb is working now. But it doesn't crash :D
20:27:44 <sech1> yeah, ci/gh-actions/depends / Win64 binary crashes, self-built doesn't crash
20:28:15 <sech1> It's probably again the same story that will only be fixed with guix builds
20:32:06 <m-relay> <w​oodser:monero.social> selsta 00e582a2b1bc6872dd8bddb31bd95bab79185ce6 is broken for me and shows these messages in monerod log repeatedly:
20:32:08 <m-relay> <w​oodser:monero.social> 2025-02-17 20:29:39.870	W Unable to send transaction(s), no available connections
20:32:10 <m-relay> <w​oodser:monero.social> 2025-02-17 20:29:39.925	E Unable to send transaction(s) via Dandelion++ stem
20:33:34 <m-relay> <w​oodser:monero.social> it's pretty easy to run the tests if more are needed
20:35:04 <m-relay> <o​frnxmr:xmr.mx> The second error should happen if you have no incoming connections, the first if you have no outgoing
20:35:27 <m-relay> <o​frnxmr:xmr.mx> do you have connections while this prints?
20:35:43 <m-relay> <w​oodser:monero.social> 2 nodes connected to each other
20:36:04 <m-relay> <w​oodser:monero.social> maybe its causing some connection issue there?
20:42:06 <selsta> woodser: does your test increase --max-connections-per-ip ?
20:43:50 <selsta> tobtoht_: can you reproduce what sech1 is seeing?
20:44:29 <m-relay> <w​oodser:monero.social> nope not that I know of
20:44:35 <selsta> can you try if that fixes it?
20:44:46 <sech1> I remember that we had random crashes when solo mining with more than 1 thread, and it was only fixed with guix builds. It's probably the same compiler issue.
20:45:07 <m-relay> <w​oodser:monero.social> only mining with one thread though
20:52:43 <sech1> found that issue: https://github.com/monero-project/monero-gui/issues/4254
20:57:02 <sech1> and the discussion of that issue https://libera.monerologs.net/monero-gui/20240301
21:05:51 <sech1> But it's a bigger problem now - the official binary couldn't mine on Windows before, now it can't sync
21:10:33 <selsta> woodser: please try with `--max-connections-per-ip 10`
21:10:44 <selsta> sech1: yes this is not something we can release hmmm
21:11:30 <selsta> at what point does it crash during sync? only at the randomx party or earlier?
21:11:35 <selsta> part*
21:12:46 <sech1> No, it crashes when syncing the first few hundred blocks (Cryptonight territory)
21:13:21 <sech1> so basically I start syncing from 0, wait a few seconds (max half a minute), and it crashes
21:16:25 <tobtoht_> selsta: I had the depends build from the fix running for a while and didn't run into any issues.
21:17:35 <m-relay> <w​oodser:monero.social> selsa starting the nodes with `--max-connections-per-ip 10000` does indeed fix the problem
21:17:42 <m-relay> <w​oodser:monero.social> and I confirmed the issue appears with PR 9460 (commit 0cd74568d6a7709c82cb12012ec952c8d00d6c96)
21:18:07 <m-relay> <w​oodser:monero.social> selsta starting the nodes with `--max-connections-per-ip 10000` does indeed fix the problem
21:20:34 <m-relay> <o​frnxmr:xmr.mx> The default setting for max-connections-per-ip is 1
21:20:37 <sech1> tobtoht_ which Windows version?
21:20:46 <tobtoht_> windows 10 22h2
21:21:49 <m-relay> <s​yntheticbird:monero.social> I'm disappointed in seeing github dropping the Windows XP service pack 1 CI
21:23:11 <sech1> huh, the binary from https://github.com/monero-project/monero/actions/runs/13376483050 seems to be working too for me now
21:23:20 <sech1> also windows 10 22h2
21:24:34 <sech1> nope, it crashed
21:25:22 <sech1> after I deleted p2pstate.bin and tried to sync again, it crashed immediately. One more attempt, and it synced 20k blocks and then crashed
21:25:42 <sech1> maybe it depends on who you connect to and how fast their connection is
21:26:27 <sech1> 3rd attempt, crashed after 12k blocks
21:28:48 <sech1> self-built binary doesn't crash, I tried 2 times so far.
21:29:24 <m-relay> <w​oodser:monero.social> `--max-connections-per-ip 10` works too
21:31:16 <sech1> what's the gcc version in  ci/gh-actions/depends/Win64 builds?
21:32:05 <sech1> 9.3.0
21:32:27 <sech1> self-built binary was built with gcc 14.2.0
21:34:51 <selsta> woodser: can it happen in your test that there is more than 1 incoming connection?
21:36:42 <m-relay> <o​frnxmr:xmr.mx> It sound like it was incorrectly allowing >1 connection per ip before
21:38:59 <tobtoht_> I deleted p2pstate a few times and let it sync, but can't repro.
21:40:31 <m-relay> <w​oodser:monero.social> there's 2 daemons talking to each other, and several wallets connecting to them. otherwise I wouldn't know. I don't do any specifically to increase incoming connections
21:46:37 <m-relay> <w​oodser:monero.social> actually like 30 wallets heh
21:48:01 <sech1> tobtoht_ how fast does it sync for you in the beginning? For me it's like 1000 blocks/second. Maybe you don't sync fast enough to crash it
21:52:13 <m-relay> <o​frnxmr:xmr.mx> sech1, 18.3.4 still syncs w/o issue?
21:52:54 <sech1> yes
21:53:09 <m-relay> <o​frnxmr:xmr.mx> did you try to totally delete the data-dir (perhaps an issue with the compression switch messed up the folder)
21:55:21 <sech1> It's not compressed
21:55:31 <sech1> I deleted it between tests
22:02:50 <m-relay> <0​xfffc:monero.social> confirming it is crashing on: https://github.com/monero-project/monero/actions/runs/13376483050
22:03:00 <m-relay> <0​xfffc:monero.social> silent crash!
22:03:37 <m-relay> <0​xfffc:monero.social> MSVC support would be useful here. I could've added MSVC native support ( exactly like bitcoin has ) in just a few days.
22:05:12 <sech1> the problem is, MSVC built binary wouldn't crash
22:05:26 <sech1> same as my local gcc-14.2.0 built binary doesn't crash
22:06:00 <sech1> unless you can make MSVC understand debug symbols from GCC
22:06:31 <sech1> https://github.com/monero-project/monero/actions/runs/13376483050 doesn't have debug symbols btw
22:07:31 <selsta> so what is the best way to continue here? bisect with depends builds? check if the PR has undefined behavior?
22:08:17 <m-relay> <0​xfffc:monero.social> VCPKG support for windows is first class. We can use it exactly same as we use depends ( like bitcoin )  https://github.com/bitcoin/bitcoin/blob/master/vcpkg.json
22:08:19 <m-relay> <0​xfffc:monero.social> bisect should be easier
22:08:33 <m-relay> <0​xfffc:monero.social> specially since we have guix build on master. https://github.com/monero-project/monero/pull/8929
22:10:06 <sech1> Bisect is probably the best option
22:10:38 <sech1> Assuming that it breaks at a specific commit and it's not some flaky compiler bug that happens in half of commits and doesn't happen in another half of commits
22:12:12 <m-relay> <0​xfffc:monero.social> That can be a huge headache. I used to fight with compiler bugs! they get extremely nasty.
22:23:00 <m-relay> <o​frnxmr:xmr.mx> sech, can you manually bisect using bins from existing actions depends builds
22:25:45 <selsta> ofrnxmr: they have their bug with blockchain getting nuked
22:26:07 <sech1> I will try
22:26:24 <sech1> Not a problem for me, I'll test it with a separate --data-dir
22:26:54 <selsta> right i guess it does not matter if you try syncing from scratch
22:28:20 <m-relay> <o​frnxmr:xmr.mx> https://github.com/monero-project/monero/actions/workflows/depends.yml?page=3&query=branch%3Arelease-v0.18 9434 is the latest from the 18.3.4 tag
22:35:36 <sech1> I bisected it to https://github.com/monero-project/monero/pull/9800
22:35:43 <sech1> builds before it don't crash
22:35:51 <m-relay> <s​yntheticbird:monero.social> Ouch
22:35:56 <m-relay> <s​yntheticbird:monero.social> boost strikes again
22:37:04 <sech1> I'm not sure such big PR even needs to go to a release branch
22:41:11 <m-relay> <s​yntheticbird:monero.social> Arch linux maintainer would like to have a word
22:50:50 <m-relay> <o​frnxmr:xmr.mx> Sech, does master crash too?
22:53:18 <m-relay> <0​xfffc:monero.social> I agree.
22:56:02 <m-relay> <p​reland:monero.social> Ah boost 🥰🤡
22:56:18 <sech1> Too late for me to test master branch today, going to sleep
22:57:07 <sech1> Testing :D
22:58:12 <sech1> Latest master seems to work fine
22:58:29 <sech1> So it's either a compiler bug, or an undefined behavior somewhere in that PR
22:59:05 <sech1> when compiled by a different compiler, or with significantly different code (master vs release), it behaves differently
22:59:55 <sech1> yep, latest master doesn't crash - 3/3 so far (50k blocks sync)
23:02:34 <selsta> master has the same PR
23:02:59 <sech1> yes, and it doesn't crash
23:03:12 <sech1> so it can be explained by an undefined behavior giving different results
23:03:37 <sech1> or a compiler bug that depends on surrounding code which is different
23:04:08 <sech1> Shame that -fsanittize=undefined doesn't build in MSYS2 (no support from compiler)
23:53:19 <m-relay> <t​obtoht:monero.social> master has boost 1.84, release 1.66. could be a boost bug