In init.cpp we call InitLoadWallet which eventually calls CWalletDB::LoadWallet which takes cs_wallet, in the course of loading the wallet it calls LoadToWallet which calls MarkConflicted which takes cs_main. This is the opposite order that these locks are taking in countless other places in the code (often in a LOCK2(cs_main, cs_wallet)). I don't think there is a risk of actual deadlock here because LoadWallet only gets called from init.cpp before network threads or rpc threads are functional. However since it causes an assertion failure with -DDEBUG_LOCKORDER it can make it difficult to do other lock order debugging.
One work around is to just not have any transactions in the wallet which need to be marked conflicted.
It may be the case that the proper lock order is actually wallet and then main, and the right fix is to actually fix all the other locks in the code, so I'm just noting the issue for now.
