Just updated a node to current master (+https://github.com/bitcoin/bitcoin/pull/7685), the node ran successfully for a couple of weeks, shortly after updating to current master, I ran in a deadlock assertion:
I think the possible deadlock is not related to the PR which I'm running on top.

```
2016-08-26 07:50:29 POTENTIAL DEADLOCK DETECTED
2016-08-26 07:50:29 Previous lock order was:
2016-08-26 07:50:29  pnode->cs_vRecvMsg  net.cpp:1885 (TRY)
2016-08-26 07:50:29  cs_main  main.cpp:4726
2016-08-26 07:50:29  (1) pfrom->cs_filter  main.cpp:4784
2016-08-26 07:50:29  (2) cs_vSend  net.cpp:2683
2016-08-26 07:50:29 Current lock order is:
2016-08-26 07:50:29  (2) pnode->cs_vSend  net.cpp:1904 (TRY)
2016-08-26 07:50:29  cs_main  main.cpp:6343 (TRY)
2016-08-26 07:50:29  pto->cs_inventory  main.cpp:6563
2016-08-26 07:50:29  (1) pto->cs_filter  main.cpp:6586
```

nSyncStarted++;
                const CBlockIndex *pindexStart = pindexBestHeader;
                /* If possible, start at the block preceding the currently
                   best known header.  This ensures that we always get a
                   non-empty list of headers back as long as the peer
                   is up-to-date.  With a non-empty response, we can initialise
                   the peer's known best block.  This wouldn't be possible
                   if we requested starting at pindexBestHeader and
                   got back an empty response.  */
                if (pindexStart->pprev)
                    pindexStart = pindexStart->pprev;
                LogPrint("net", "initial getheaders (%d) to peer=%d (startheight:%d)\n", pindexStart->nHeight, pto->id, pto->nStartingHeight);
                pto->PushMessage(NetMsgType::GETHEADERS, chainActive.GetLocator(pindexStart), uint256());
            }
        }
        
        
        
        if (!fReindex && !fImporting && !IsInitialBlockDownload())
        {
            GetMainSignals().Broadcast(nTimeBestReceived);
        }
        
        
        
        {