demiaowu
commented
5 years ago 更新一下我们的分析进度：
（1）主要原因：
根据上面core dump和日志，我们发现死锁和新原因是Follower Abraft::LocalSnapshotCopier::copy_file从session->join();唤醒之后，如下代码调lck.lock()，发现此lck已经被当前pthread lock 过了，并且没有unlock，那么造成下面调lck.lock()拿不到锁，这样就死锁了。相当于一个bthread拿到了一把锁，没有释放又去拿这把锁，从而造成死锁，自己把自己给锁死了。
void LocalSnapshotCopier::copy_file(const std::string& filename) {
......
lck.unlock();
session->join();
lck.lock();
.......这个bthread的调度看上去几乎不能避免这个问题
（2）死锁场景复现分析
结合coredump 和日志，我们给出一种死锁场景复现分析：
（2.1）Follower A下载快照，负责下载快照的bthread等待某个下载文件完成的之后切出去
第1步：I0603 11:26:01.204864 579067 node.cpp:2354] node 4294969292:10.182.26.0:8216:0 received InstallSnapshotRequest last_included_log_index=68275306 last_include_log_term=40 from 10.182.26.1:8217:0 when last_log_id=(index=67858560,term=23) 下载快照，进入copy_file下载某个文件，session->join(); 这个bthread切出去，切出去之后，已经将锁释放，这个时候，没有拿到任何的lock
（2.2）Follower A收到更大term的RequestVote，然后step down，执行打断interrupt_downloading_snapshot的逻辑，日志如下：
I0603 11:28:00.075150 579082 node.cpp:1946] node 4294969292:10.182.26.0:8216:0 received RequestVote from 10.182.26.2:8206:0 in term 41 current_term 40
第1步：NodeImpl::handle_request_vote_request处理投票请求，拿到NodeImpl 的mutex
第2步：NodeImpl::step_down，执行打断当前正在下载的snapshot _snapshot_executor->interrupt_downloading_snapshot(term)
第3步：interrupt_downloading_snapshot拿到SnapshotExecutor的mutex，执行_cur_copier->cancel()
第4步：LocalSnapshotCopier::cancel拿到 LocalSnapshotCopier的mutex，调用_cur_session->cancel()
第5步：Session::cancel拿到 RemoteFileCopier的mutex，然后执行rpc::StartCancel(_rpc_call);取消session那边下载文件的rpc，通过ECANCELED错误和on_finished();，通过_finish_event.signal();唤醒（2.1）的session.join()
问题来，如果第5步，拿到了LocalSnapshotCopier和RemoteFileCopier等的mutex之后，切出去，并且（2.2）和（2.1）运行在同一个worker pthread空间上，那么（2.2）的第5步切换出去，（2.1）切换进来掉lck.lock()，那么就死锁了。
实际上，从上面的堆栈来看，on_rpc_returned、'copy_file'、handle_append_entries_request、handle_election_timeout就都会拿不到锁，从而最后将整个bthread的theadpool都锁死掉了
PFZheng
chenzhangyi
cl079074282
helloworld0xff
代码版本：release 版本 1.0.1 场景：一个进程有上百个落后的copyset，重启后并发恢复出现死锁，gdb堆栈如下：
通过gdb分析发现，确实存在死锁的现象： 现象（1）所有卡在
braft::LocalSnapshotCopier::copy_file的thread，都在等LocalSnapshotCopier的_mutex，但是gdb发现这个pthread已经持有了这把锁，所以再次进入的时候会死锁，例如上面堆栈的Thead 14、18、21、22、69等 现象（2）所有卡在braft::RemoteFileCopier::Session::on_rpc_returned的thread，都在等RemoteFileCopier的_mutex，但是gdb显示，这把锁都被卡在braft::LocalSnapshotCopier::copy_file的线程持有了，类似的线程有Thread 16，它需要的锁已经被Thread 69持有，而Thread 69又死锁了，也就是卡在braft::LocalSnapshotCopier::copy_file中这里根本的原因就是现象（1）死锁了，导致一连串的死锁，理论上在install snapshot的时候怎么会拿到LocalSnapshotCopier的_mutex之后又重新尝试拿这把锁？这跟bthread调度有关吗？感觉像是bthread拿到了_mutex，又切换出去，然后切换进来的新bthread，又去拿这把_mutex，从而造成了死锁。
不知道你们有遇到类似的问题没？附上部分日志：