Skip to content

Conversation

@rustyrussell
Copy link
Contributor

Fixes: #8634

We call it once at the end, but calling on each allocation is
excessive, and it shows when dealing with large PSBTS.  Testing a
700-input PSBT was unusably slow without this: after this the entire
test ran in 9 seconds.

Changelog-Fixed: JSON-RPC: Dealing with giant PSBTs (700 inputs!) is now much faster.
Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell added this to the v25.12 milestone Oct 28, 2025
@rustyrussell rustyrussell added the 25.09.2 Candidates if we do a 25.09.2 label Oct 28, 2025
@rustyrussell rustyrussell force-pushed the guilt/giant-tx-fix branch 2 times, most recently from 6c0eb3e to 1c84919 Compare October 31, 2025 03:52
"""Test that a giant tx doesn't crash bcli"""
l1 = node_factory.get_node(start=False)
# With memleak we spend far too much time gathering backtraces.
del l1.daemon.env["LIGHTNINGD_DEV_MEMLEAK"]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this line is causing your test to fail. It seems like the LIGHTNINGD_DEV_MEMLEAK key does not exist under valgrind? You can use .pop() instead of del, that way the key will be removed only if it exists.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea why the liquid test fails like this though:

FAILED tests/test_plugin.py::test_bitcoin_backend_gianttx - pyln.client.lightning.RpcError: RPC call failed: method: withdraw, payload: {'destination': 'el1qqwawntx90mlylxle6q3vwjcm9r5fc7te6nf58gq469ejxym6fuv5sl6fhxnuat264hf86vmh6h0qupv99flgsy8hhudn3t32f', 'satoshi': 'all'}, error: {'code': -1, 'message': 'Could not parse destination address, destination should be a valid address'}

It seems like l1 is a liquid node, and we're trying to withdraw to a correct liquid address?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this line is causing your test to fail. It seems like the LIGHTNINGD_DEV_MEMLEAK key does not exist under valgrind? You can use .pop() instead of del, that way the key will be removed only if it exists.

pop still raises on missing (according to the docs), so I just tested before delete.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea why the liquid test fails like this though:

FAILED tests/test_plugin.py::test_bitcoin_backend_gianttx - pyln.client.lightning.RpcError: RPC call failed: method: withdraw, payload: {'destination': 'el1qqwawntx90mlylxle6q3vwjcm9r5fc7te6nf58gq469ejxym6fuv5sl6fhxnuat264hf86vmh6h0qupv99flgsy8hhudn3t32f', 'satoshi': 'all'}, error: {'code': -1, 'message': 'Could not parse destination address, destination should be a valid address'}

It seems like l1 is a liquid node, and we're trying to withdraw to a correct liquid address?

Ah, we have a getnewaddress() wrapper which gives us an unconfidential address: need to use that for elements!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this line is causing your test to fail. It seems like the LIGHTNINGD_DEV_MEMLEAK key does not exist under valgrind? You can use .pop() instead of del, that way the key will be removed only if it exists.

pop still raises on missing (according to the docs), so I just tested before delete.

Sorry, I probably should have elaborated on what I meant when I said to use .pop(), you can use .pop() with a default argument which is returned when the key isn't found in the dictionary. So you can call it like this:

l1.daemon.env.pop("LIGHTNINGD_DEV_MEMLEAK", None)

But a test works too!

```
lightningd-1 2025-10-27T11:26:04.285Z **BROKEN** plugin-bcli: bitcoin-cli exec failed: Argument list too long
```

Use -stdin to bitcoin-cli: we can then handle arguments of arbitrary length.

Fixes: ElementsProject#8634
Changelog-Fixed: plugins: `bcli` would fail with "Argument list too long" when sending a giant tx.
@rustyrussell rustyrussell merged commit 43d7db7 into ElementsProject:master Nov 3, 2025
34 of 38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

25.09.2 Candidates if we do a 25.09.2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

crash: /usr/local/bin/bitcoin-cli exec failed: Argument list too long

3 participants