Bitcoin full node and query server
Mar 3, 2020
View in context in the libbitcoin Slack #general mirror.
vdeurzen22:50
From my gdb and printf debugging I'm seeing that p2p::close() is hanging, specifically it's stuck joining all threads in the threadpool, somewhere in there something is causing some kind of deadlock. I've seen this on my production nodes, my local dev nodes on my laptop and my desktop machine, it's quite reproducible, but hard to track down
19 replies · evoskuil, vdeurzen · last Mar 04, 2020
evoskuil09:18
That’s where I would expect it. It is hard to track down and I haven’t had a chance to do it yet. One of the reasons v4 is not released.
vdeurzen09:19
I had a similar issue in v3 before, might be a different one but the behaviour ended up being about the same
vdeurzen09:21
What I'm seeing after adding a bunch of debug logs is that p2p::close is being called more than once
I also see there is a potential race between threadpool::shutdown, threadpool::join and threadpool::spawn_once. The shutdown method will reset
work which can be re-initialized by spawn_once and could cause join to need to wait for more work to be finished.evoskuil10:10
I don’t believe you will find any actual issue in the thread pool, but I can’t comment on specifics from my phone.
vdeurzen10:12
The race between shutdown and spawn_once is easy to argue I think, after
shutdown before close, a spawn_once will re-initialize work. However, I don't know if reinitializing work is what is causing thisevoskuil10:17
If a thread is being initialized it has a close that is registered after the initialization.
evoskuil11:06
It is managed by requiring a close handler to be registered upon completion of any thread spawn call.