ghost43

Note: if we reuse an expired address and call `wallet.create_request` with that addr, we should also consider explicitly deleting the expired request from the wallet. Previously this was done implicitly...

> Perhaps we should not use the address as key in `get_key_for_receive_request`, when `is_lightning` is `False` That way, when a non-lightning request has expired, it would be possible to create...

So this is on the 1.15 tag (835aa492e9a3563d89d99c35168378d65321b849) now? Then it's been there for multiple months -- or did it only start happening recently? You can try running something like...

It's in my personal fork https://github.com/sombernight/electrumx/commit/53fbeb7241c8466645153890f719ab45ed1624ed

Could you grep the logs for `hellothere`? `... | grep "hellothere" -A 20`

I have 3316 MB RES usage on mainnet, after 10 days of uptime (running ~master. self-note: https://github.com/spesmilo/electrumx/commits/1d7b38d35bf475e9651ae470ff8d94d76f70375d) So no, not sure there is a leak here. Maybe try without uvloop?

but before you restart, could you grep the logs for `hellothere` again?

I have this traceback for the main thread, on python 3.8.5 (from ubuntu 20.04; with `openssl=1.1.1f-1ubuntu2.3`). It is similar to the one in the OP. ```gdb (gdb) py-bt Traceback (most...

> Note that around line https://github.com/python/cpython/blob/v3.8.5/Lib/asyncio/sslproto.py#L262, `exc_errno = 5` corresponds to > ``` > >>> ssl.SSL_ERROR_SYSCALL > > ``` I have been running with a patched python for the last...

I've opened upstream python bug report: https://bugs.python.org/issue44036