@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.

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?

.merge+ 9403 9428

Added

I have trouble building the release branch in MSYS2, I get linking errors: paste.debian.net/hidden/ac3578ef

If anyone can recognize them, maybe you know how to fix it quicklyy

Some conflict between libunwind.a and libgcc_eh.a

sech1: is this with updating all msys2 packages?

release-v0.18 msys2 ci was successful yesterday github.com/monero-project/monero/ac…ns/runs/13352067922/job/37289871151

Yes, I did "pacman -Syuu" several times before building

Manually disabling libunwind in CMakeLists.txt fixed the issue, but now I won't get callstacks if something happens

it's possible we don't have libunwind installed with CI builds

.merge+ 9439 9438

Added

yeah, my MSYS2 installation is several years old and I've installed and built a lot of different stuff there

wtf, the binary I build just nuked my blockchain and started downloading it from 0

*built

stopped it, started again and it started from 0 again (nuking the previous data.mdb)

i don't think we have any code that can delete the data.mdb

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

I can reproduce it consistently, it just refuses to load data.mdb that is there and starts from 0

log level 3 didn't clear up things for me

I think my binary build is broken somehow, I'll revert to v0.18.3.4 for now

I'll build the gitian build later to see if it has the same issue

<o​frnxmr:xmr.mx> 👀

<j​effro256:monero.social> sech1: what does running `mdb_stat -rr <MONERO DATA DIR>/lmdb` return ?

Where do I get mdb_stat?

<j​effro256:monero.social> You can build mdb_stat from the external/db_drivers/liblmdb Makefile

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)

So when it nuked the blockchain first time, it wasn't corrupt 100%

I'm building gitian build of the latest release-v0.18 branch, I'll try it when it finishes

<j​effro256:monero.social> Someone else was posting that running the latest release-v0.18 caused crashes from stale readers

<j​effro256:monero.social> That's what I've been attempting to debug for the last 2 days

<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

<o​frnxmr:xmr.mx> Jeffro, windows the issue youre looking at too?

<o​frnxmr:xmr.mx> If using release branch with xmrblocks (onion explorer) it doesnt work

<j​effro256:monero.social> Nope on Linux

<j​effro256:monero.social> How doesn't it work in your case?

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.

<o​frnxmr:xmr.mx> onion explorer devel branch pairs withonero master

<o​frnxmr:xmr.mx> Their master branch pairs with monero latest release tag

<o​frnxmr:xmr.mx> Their devel branch already has c++17 moneroexamples/onion-monero-blockchain-explorer #325

<o​frnxmr:xmr.mx> moneroexamples/onion-monero-blockchain-explorer 5285f9c

<o​frnxmr:xmr.mx> Building onion master against monero release-v0.18 requires this pr moneroexamples/onion-monero-blockchain-explorer #320

sech1: github.com/monero-project/monero/actions/runs/13374316072 this has a windows build artifact for release-v0.18

selsta yeap, same behavior. It nuked blockchain again and started from 0

at least it's 100% reproducible, should be easy to debug

and it's unstable, crashes during sync

will go through all commits merged since the last release and check if anything touches the database

<j​effro256:monero.social> PRs monero-project/monero #9689 and monero-project/monero #9622 touch the cryptonote_core/blockchain.cpp since v0.18.3.4

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

and then even crashes during sync

<j​effro256:monero.social> Is there a crash message?

.merge+ 9802 9803

Added

No, it just exits

with no message

<j​effro256:monero.social> PRs monero-project/monero #9705 and monero-project/monero #9702 touch cryptonote_db/ folder since v0.18.3.4

log level 2 doesn't show anything interesting

<j​effro256:monero.social> Both of the latter are Windows related

I didn't see messages from 9702

9705 looks sus

boost::filesystem::file_size might not work at all

<j​effro256:monero.social> Should be commit 6392361d62d47b74977e1b4f31a6db48a706f083 on the release-v0.18 branch

but that commit doesn't explain why it crashes during sync

hi guys

<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

i am new to crypto

how does xmr prevent replay attacks

So the latest release-v0.18 can't sync on Windows (crash) and can't load the existing database (overwriting it in the process)

my bad i am in #monero now

sech1: reproducible with gitian?

gitian still building and will take several hours because I nuked gitian files before to free space

<0​xfffc:monero.social> Give me a little bit of time ( 2 h) . I will compile it on windows and debug it.

<0​xfffc:monero.social> Possible?

<o​frnxmr:xmr.mx> You can test it here github.com/monero-project/monero/actions/runs/13374316072

<o​frnxmr:xmr.mx> Backup your blockchain first

tobtoht_: it's reproducible with depends builds so likely also gitian

yep can reproduce with depends

it should be easy to git bisect the issue

<o​frnxmr:xmr.mx> If you have a windows box 🥸

<j​effro256:monero.social> sech1: is is reproducible with `--offline`?

But it doesn't sync with --offline? If you're talking about blockchain nuking, then probably yes because it happens very early during startup

I can't test now, syncing again with v0.18.3.4. I need to restore my node.

my bisect came up with this: monero-project/monero #9702

will revert locally to double-check

<j​effro256:monero.social> Perhaps the `CreateFileW` call?

<j​effro256:monero.social> I think I found it

<j​effro256:monero.social> Will PR in a couple minuts

jeffro256: if you touch that code can you also fix the `compressend` typo?

<j​effro256:monero.social> Of course

boost::filesystem::ofstream(datafile).close(); // touch the file to ensure it exists

lol

"touch" by rewriting it

yeah, that explains why it gets nuked

but it doesn't explain random crashes during sync

<o​frnxmr:xmr.mx> Maybe it doesnt like to be touched .. ptsd

<j​effro256:monero.social> Yup

<j​effro256:monero.social> `boost::filesystem::ofstream` always truncates by default

I think that line is not needed at all

"data.mdb" will be created elsewhere when it's needed

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

It would eventually be caught on a second run, but it might cause failures that first run

yeah

jeffro256: also against release

<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?

<o​frnxmr:xmr.mx> wdym by not immediately mined? What miner are you using?

<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.

<o​frnxmr:xmr.mx> if youre using xmrig, then there is a 15 second job timeout by default

<w​oodser:monero.social> just using monerod to mine, and yeah, the tx isn't being confirmed when blocks are mined

<o​frnxmr:xmr.mx> Reproducibly?

.merge+ 9804 9805

Added

<w​oodser:monero.social> reproducibly in haveno tests when the payout is made, yes

<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

woodser: can you test if you can reproduce the issue with 9460 reverted?

<w​oodser:monero.social> yes

<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?

You can checkout 1 commit before it and test :P

<w​oodser:monero.social> sure

<o​frnxmr:xmr.mx> e488bc838a73f238fb31084dad344350c005654e

9460 caused sporadic issues with the p2p functional test but we thought it was related to the test itself being buggy monero-project/monero #9755

so it is my best guess for the issue you are seeing woodser

<w​oodser:monero.social> e488bc is working fine in my tests

how easy is it to run the haveno tests?

<o​frnxmr:xmr.mx> woodser

<p​reland:monero.social> From my experience, it is anywhere from very easy to very difficult

<p​reland:monero.social> The only way to find out which one it’ll be is to try lol

<s​yntheticbird:monero.social> Elected most insightful insight of 2025 🏆️

<p​reland:monero.social> 😂

<p​reland:monero.social> Actually I’m just going to say that it’s incredibly difficult and it will be a challenge

<p​reland:monero.social> That way when they try it, it’ll logically work perfectly with no issues

woodser: can you also test commit 00e582a2b1bc6872dd8bddb31bd95bab79185ce6 to make sure it is 9460?

<w​oodser:monero.social> yep testing

I'm testing monero-project/monero 0232839 (the latest from release-v0.18 branch). It doesn't delete the DB anymore, but it still crashes when syncing (and quickly).

<o​frnxmr:xmr.mx> No log for the crash?

No

Exception thrown at 0x0000000000DA3930 in monerod.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

That's all I have

mov rdx,qword ptr [rax]

rax is 0

I'll try to build and run under gdb, but it never worked for me on Windows

huh, gdb is working now. But it doesn't crash :D

yeah, ci/gh-actions/depends / Win64 binary crashes, self-built doesn't crash

It's probably again the same story that will only be fixed with guix builds

<w​oodser:monero.social> selsta 00e582a2b1bc6872dd8bddb31bd95bab79185ce6 is broken for me and shows these messages in monerod log repeatedly:

<w​oodser:monero.social> 2025-02-17 20:29:39.870 W Unable to send transaction(s), no available connections

<w​oodser:monero.social> 2025-02-17 20:29:39.925 E Unable to send transaction(s) via Dandelion++ stem

<w​oodser:monero.social> it's pretty easy to run the tests if more are needed

<o​frnxmr:xmr.mx> The second error should happen if you have no incoming connections, the first if you have no outgoing

<o​frnxmr:xmr.mx> do you have connections while this prints?

<w​oodser:monero.social> 2 nodes connected to each other

<w​oodser:monero.social> maybe its causing some connection issue there?

woodser: does your test increase --max-connections-per-ip ?

tobtoht_: can you reproduce what sech1 is seeing?

<w​oodser:monero.social> nope not that I know of

can you try if that fixes it?

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.

<w​oodser:monero.social> only mining with one thread though

found that issue: monero-project/monero-gui #4254

and the discussion of that issue libera.monerologs.net/monero-gui/20240301

But it's a bigger problem now - the official binary couldn't mine on Windows before, now it can't sync

woodser: please try with `--max-connections-per-ip 10`

sech1: yes this is not something we can release hmmm

at what point does it crash during sync? only at the randomx party or earlier?

part*

No, it crashes when syncing the first few hundred blocks (Cryptonight territory)

so basically I start syncing from 0, wait a few seconds (max half a minute), and it crashes

selsta: I had the depends build from the fix running for a while and didn't run into any issues.

<w​oodser:monero.social> selsa starting the nodes with `--max-connections-per-ip 10000` does indeed fix the problem

<w​oodser:monero.social> and I confirmed the issue appears with PR 9460 (commit 0cd74568d6a7709c82cb12012ec952c8d00d6c96)

<w​oodser:monero.social> selsta starting the nodes with `--max-connections-per-ip 10000` does indeed fix the problem

<o​frnxmr:xmr.mx> The default setting for max-connections-per-ip is 1

tobtoht_ which Windows version?

windows 10 22h2

<s​yntheticbird:monero.social> I'm disappointed in seeing github dropping the Windows XP service pack 1 CI

huh, the binary from github.com/monero-project/monero/actions/runs/13376483050 seems to be working too for me now

also windows 10 22h2

nope, it crashed

after I deleted p2pstate.bin and tried to sync again, it crashed immediately. One more attempt, and it synced 20k blocks and then crashed

maybe it depends on who you connect to and how fast their connection is

3rd attempt, crashed after 12k blocks

self-built binary doesn't crash, I tried 2 times so far.

<w​oodser:monero.social> `--max-connections-per-ip 10` works too

what's the gcc version in ci/gh-actions/depends/Win64 builds?

9.3.0

self-built binary was built with gcc 14.2.0

woodser: can it happen in your test that there is more than 1 incoming connection?

<o​frnxmr:xmr.mx> It sound like it was incorrectly allowing >1 connection per ip before

I deleted p2pstate a few times and let it sync, but can't repro.

<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

<w​oodser:monero.social> actually like 30 wallets heh

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

<o​frnxmr:xmr.mx> sech1, 18.3.4 still syncs w/o issue?

yes

<o​frnxmr:xmr.mx> did you try to totally delete the data-dir (perhaps an issue with the compression switch messed up the folder)

It's not compressed

I deleted it between tests

<0​xfffc:monero.social> confirming it is crashing on: github.com/monero-project/monero/actions/runs/13376483050

<0​xfffc:monero.social> silent crash!

<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.

the problem is, MSVC built binary wouldn't crash

same as my local gcc-14.2.0 built binary doesn't crash

unless you can make MSVC understand debug symbols from GCC

github.com/monero-project/monero/actions/runs/13376483050 doesn't have debug symbols btw

so what is the best way to continue here? bisect with depends builds? check if the PR has undefined behavior?

<0​xfffc:monero.social> VCPKG support for windows is first class. We can use it exactly same as we use depends ( like bitcoin ) github.com/bitcoin/bitcoin/blob/master/vcpkg.json

<0​xfffc:monero.social> bisect should be easier

<0​xfffc:monero.social> specially since we have guix build on master. monero-project/monero #8929

Bisect is probably the best option

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

<0​xfffc:monero.social> That can be a huge headache. I used to fight with compiler bugs! they get extremely nasty.

<o​frnxmr:xmr.mx> sech, can you manually bisect using bins from existing actions depends builds

ofrnxmr: they have their bug with blockchain getting nuked

I will try

Not a problem for me, I'll test it with a separate --data-dir

right i guess it does not matter if you try syncing from scratch

<o​frnxmr:xmr.mx> github.com/monero-project/monero/ac…page=3&query=branch%3Arelease-v0.18 9434 is the latest from the 18.3.4 tag

I bisected it to monero-project/monero #9800

builds before it don't crash

<s​yntheticbird:monero.social> Ouch

<s​yntheticbird:monero.social> boost strikes again

I'm not sure such big PR even needs to go to a release branch

<s​yntheticbird:monero.social> Arch linux maintainer would like to have a word

<o​frnxmr:xmr.mx> Sech, does master crash too?

<0​xfffc:monero.social> I agree.

<p​reland:monero.social> Ah boost 🥰🤡

Too late for me to test master branch today, going to sleep

Testing :D

Latest master seems to work fine

So it's either a compiler bug, or an undefined behavior somewhere in that PR

when compiled by a different compiler, or with significantly different code (master vs release), it behaves differently

yep, latest master doesn't crash - 3/3 so far (50k blocks sync)

master has the same PR

yes, and it doesn't crash

so it can be explained by an undefined behavior giving different results

or a compiler bug that depends on surrounding code which is different

Shame that -fsanittize=undefined doesn't build in MSYS2 (no support from compiler)

<t​obtoht:monero.social> master has boost 1.84, release 1.66. could be a boost bug