💬 Farnoosh85 commented on issue "test: `wallet_importdescriptors.py --descriptors` failure":
(https://github.com/bitcoin/bitcoin/issues/27282#issuecomment-1817733980)
27229

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817748721)
> The point is that the former log shows the first flush. In the latter one, there were no flushes by that point at all.

That's ok, with pool it flushes later. But on second glance, the cache size is incorrect: `cache=26.3MiB(3276665txo)`
That's not possible, there's cache can only be 26.3MiB with 3276665tx in it. So this looks like the cache size estimation doesn't work for some reason. Can you post the full log?

📝 cloudbed1 opened a pull request: "Create Web-Scale Blockchain for fast,"
(https://github.com/bitcoin/bitcoin/pull/28910)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

✅ cloudbed1 closed a pull request: "Create Web-Scale Blockchain for fast,"
(https://github.com/bitcoin/bitcoin/pull/28910)

📝 achow101 locked a pull request: "."
(https://github.com/bitcoin/bitcoin/pull/28910)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

⚠️ fujicoin opened an issue: "Signet mining is not possible when using descriptor wallet"
(https://github.com/bitcoin/bitcoin/issues/28911)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Signet mining is not possible when using descriptor wallet.
The error message is "PSBT signing failed"

Errors were confirmed in the following two cases.
1. In an environment where mining is performed using a legacy wallet, the wallet is changed to a descriptor type using the "migratewallet" command.
2. A case where the private key descriptor of the address that generated the signetch
...

💬 martinus commented on issue "v26.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/28718#issuecomment-1817780006)
The log `[...] cache=232.0MiB(31044257txo)` indicates that here too something might be wrong with the `DynamicMemory` calculation. when having 31 million txo in memory cache size should be much higher.

💬 helpau commented on issue "Sync slow":
(https://github.com/bitcoin/bitcoin/issues/26063#issuecomment-1817784916)
Here's what I did to get logs with [lock] entries
1)Downloaded the release 25.1 source code, installed VS 2022
2)Installed qt with the -debug-and-release parameter
3)Installed the dependencies via vcpkg
4)Specified DEBUG_LOCKCONTENTION parameter for libbitcoin_utul project, started Debug solution build, ran bitcoin-qt.exe with -debug=1, didn't get [lock]'s
5)Tried to add DEBUG_LOCKORDER parameter, but with it the build failed (bug?).
If I can't build the solution, I will try to reproduce t
...

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817788182)
> Can you post the full log?

See https://github.com/hebasto/artefacts/blob/arm-OOM-logs/arm-OOM-logs/debug.log-04fb0b35cf18

👍 vasild approved a pull request: "test: fix `AddNode` unit test failure on OpenBSD"
(https://github.com/bitcoin/bitcoin/pull/28891#pullrequestreview-1738598461)
ACK 007d6f0e85bc329040bb405ef6016339518caa66

⚠️ maflcko reopened an issue: "Sync slow"
(https://github.com/bitcoin/bitcoin/issues/26063)
Syncing blockchain is sometimes very slow. I think this has become more common in the past months.

Here's a screenshot from Network Traffic window in the GUI, see how there are long periods of absolutely no traffic. Also see how it only downloaded about 100 MB during the first 30minutes of syncing. It's also often connected to just 1 or 2 peers which is weird.

![bitcointrafficverylowandslow](https://user-images.githubusercontent.com/79941375/189544394-3cb3dd32-b384-437e-a785-456b149b0258.p
...

💬 maflcko commented on pull request "bench: add readblock benchmark":
(https://github.com/bitcoin/bitcoin/pull/26684#discussion_r1398383803)
```suggestion
DataStream stream{benchmark::data::block413567};
```

(see compile failure)

💬 maflcko commented on pull request "depends: bump libmultiprocess to fix capnproto deprecation warnings":
(https://github.com/bitcoin/bitcoin/pull/28907#issuecomment-1817829246)
lgtm ACK 21bfee0720ba72935d4f9fc4c2a2887ae5b54092

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817833689)
Thanks a lot for the log! I am now pretty certain that the allocated blocks from the pool are not counted in `DynamicUsage`. I can reproduce practically exactly same cache sizes as in the log when I set `usage_chunks=0` here (and run 32bit bitcoind on x86): https://github.com/bitcoin/bitcoin/blob/master/src/memusage.h#L201
So the `bucket_count` is calculated correctly which can be seen by the memory jumps.

So either `pool_resource->ChunkSizeBytes()` or `pool_resource->NumAllocatedChunks()`
...

💬 sipa commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817834734)
@martinus Is it possible that due to a mistake in the guessed node size, the utxo cache entries are allocated through the fallback to the normal allocator?

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817837129)
> @martinus Is it possible that due to a mistake in the guessed node size, the utxo cache entries are allocated through the fallback to the normal allocator?

Which part of code is responsible for that?

💬 sipa commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817838140)
@hebasto The guess for node size is here: https://github.com/bitcoin/bitcoin/blob/v26.0rc2/src/coins.h#L146

Can you try increasing that (say, add 64 to it), and see if that fixes things?

💬 martinus commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817845209)
> @martinus Is it possible that due to a mistake in the guessed node size, the utxo cache entries are allocated through the fallback to the normal allocator?

That sounds like a very likely explanation! Although I'm curious why the estimation would work in x86 32bit but not on ARM

💬 hebasto commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817845764)
Might it depend on `max_load_factor`?

💬 sipa commented on issue "RAM usage regression in 26.x and master on ARM 32-bit":
(https://github.com/bitcoin/bitcoin/issues/28906#issuecomment-1817848079)
@hebasto No, it shouldn't.

We're essentially trying to guess the `sizeof` of an internal data structure in `std::unordered_map`. If we guess too small, allocations do not go to the pool, but a fallback to the normal allocator is used.

@martinus Should we make sure that even allocations that use the fallback get accounted for in the resource?