Memory leak via API listtransactions #25229

1. 
   CWDT250 commented at 6:25 pm on May 27, 2022: none

   Hello. I use a bitcoind with a large wallet containing about 150K transactions. Each time the method listtransactions is used the memory consumed by the process grows 100MB. As a result it can take up all possible memory and ends with a kill signal.

   System information: Bitcoin Core 23.0 CentOS 8.4 CPU Cores: 12 RAM: 64GB SSD: 1TB

2. CWDT250 added the label Bug on May 27, 2022
3. fanquake added the label Resource usage on May 27, 2022
4. maflcko added the label Wallet on May 28, 2022
5. 
   mzumsande commented at 6:35 pm on May 29, 2022: contributor

   I tried to reproduce this (Ubuntu 20.04.4 LTS) with a large wallet but could not see a memory leak (also not with valgrind). What I did see is that repeated calls to listtransactions would lead to a step up in the memory claimed by bitcoind (as seen by top or pmap) that would not be released by the OS (enhanced by the fact that the memory for the large RPC response was reserved twice, fixed in #25237) But after ~5 calls to listtransactions the memory of bitcoind would not increase any further for me with more listtransactions calls.
6. 
   CWDT250 commented at 9:28 pm on May 29, 2022: none

   My application is querying listtransactions "*" 100000000 about once every 1 minute to retrieve a list of all transactions. The request takes about 10 seconds. After each call there is an increase in the consumed memory. Sometimes memory clearing is observed but this is useless and after 2-3 hours bitcoind dies with a kill signal from the OS.

   I also additionally checked after 5 or more calls the memory also grows by 100+ MB.

7. fanquake referenced this in commit e3b7f10b10 on May 30, 2022
8. bitcoin deleted a comment on May 30, 2022
9. bitcoin deleted a comment on May 30, 2022
10. bitcoin deleted a comment on May 30, 2022
11. sidhujag referenced this in commit 38c4651715 on May 30, 2022
12. fanquake referenced this in commit 081965ccc3 on Jul 13, 2022
13. sidhujag referenced this in commit ab03ad1891 on Jul 13, 2022
14. 
    fanquake commented at 8:54 am on August 9, 2022: member

    Bitcoin Core 23.0 @CWDT250 are you able to test the behaviour using a build of the master branch?

15. 
    maflcko commented at 8:56 am on August 10, 2022: member

    I could reproduce a memory increase in the system monitor, but not in massif.
16. 
    aureleoules commented at 3:29 pm on October 10, 2022: member

    I also tried to reproduce the memory leak (in master 57c192767b0e24e51f2f777668ba6f5173f8960d). I ran listtransactions a lot of times on a large wallet (54,000 txs, some coinbases, some regular transactions). The first 4-5 calls increased the memory usage of bitcoind but then it stabilizes and didn’t increase RAM usage, I’m guessing that could be cache?
17. 
    liorwavebl commented at 2:55 pm on October 20, 2022: none

    I have a large wallet with 515K transactions. When I’m calling listunspent the memory increases after a new call. After 10 times the bitcoin server crashes.
18. 
    w0xlt commented at 3:12 pm on October 20, 2022: contributor

    listunspent does not return the number of transactions, but the number of coins available for the wallet. How many items does this listunspent response return?
19. 
    liorwavebl commented at 3:19 pm on October 20, 2022: none

    @w0xlt the output has 5662758 lines, equivalent to ~515K transactions. My point is that the same behavior exists in listunspent and not only in listransactions.
20. 
    maflcko commented at 5:57 pm on April 16, 2024: member

    I don’t think there is anything that can be done here. The final JSON RPC reply fully written to a single byte buffer must be stored in memory contiguously. If such an amount of memory is not available, it needs to be allocated.

    In theory it could be released, for example by malloc_trim, but what would be the point, if on the next RPC call it will need to be allocated again?

21. maflcko closed this on Apr 16, 2024

    ---

22. maflcko removed the label Bug on Apr 16, 2024
23. maflcko added the label RPC/REST/ZMQ on Apr 16, 2024
24. maflcko removed the label Wallet on Apr 16, 2024
25. 
    maflcko commented at 6:00 pm on April 16, 2024: member

    If you are looking for a workaround, you can either provide more memory (or swap), or you could try to call the RPC with smaller count values.

Contributors
CWDT250 mzumsande fanquake maflcko aureleoules liorwavebl w0xlt

Labels
RPC/REST/ZMQ Resource usage