花費(fèi)了比較長(zhǎng)的時(shí)間，解決了編譯過程中遇到的許多問題后，終于把這個(gè)開源的工程編譯好了，運(yùn)行post build 腳本將需要的鏈接文件拷貝好。正當(dāng)我以為沒有任何問題了，雙擊可執(zhí)行程序運(yùn)行。

結(jié)果運(yùn)行起來的時(shí)候報(bào)錯(cuò)了，提示無法正常啟動(dòng)，根據(jù)這個(gè)這個(gè)報(bào)錯(cuò)的提示，網(wǎng)上搜了一下，都說是缺少dll庫(kù)導(dǎo)致的，于是將post build腳本又運(yùn)行了一遍，重新雙擊打開可執(zhí)行程序，還是報(bào)一樣的錯(cuò)。

那么是缺少那個(gè)dll庫(kù)導(dǎo)致的呢？于是我打開系統(tǒng)的事件查看器，從里面找到了應(yīng)用程序錯(cuò)誤事件，點(diǎn)擊看到了詳細(xì)信息，從描述來看出錯(cuò)的模塊是libprotobufd.dll，是在運(yùn)行這個(gè)dll的過程中出現(xiàn)的異常，并非缺少dll導(dǎo)致。

{// Use IntelliSense to learn about possible attributes.// Hover to view descriptions of existing attributes.// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387"version": "0.2.0","configurations": [{"name": "(msvc) launch","type": "cppvsdbg","request": "launch","program": "D:\\Kicad\\kicad-source-mirror\\build\\out\\bin\\kicad.exe"}]
}

為了進(jìn)一步弄清楚這個(gè)庫(kù)出錯(cuò)的原因和位置，于是在vscode編輯器中將C/C++相關(guān)的插件安裝上，設(shè)置好debug條件，運(yùn)行debug功能后，跳轉(zhuǎn)到了出現(xiàn)異常的代碼位置。

從給的錯(cuò)誤信息可以看出來_Pnext是一個(gè)非法值，那么這個(gè)值為什么是一個(gè)非法值，目前猜測(cè)它是一個(gè)空指針，或者指向的內(nèi)存不對(duì)，目前只是有這樣一個(gè)概念，帶著這樣的疑惑繼續(xù)分析原因。

_EXPORT_STD template <class _Ty, class _Other = _Ty>
_CONSTEXPR20 _Ty exchange(_Ty& _Val, _Other&& _New_val)noexcept(conjunction_v<is_nothrow_move_constructible<_Ty>, is_nothrow_assignable<_Ty&, _Other>>) {// assign _New_val to _Val, return previous _Val_Ty _Old_val = static_cast<_Ty&&>(_Val);_Val         = static_cast<_Other&&>(_New_val);return _Old_val;
}

exchange的作用是將第一個(gè)參數(shù)設(shè)置成第二個(gè)參數(shù)的值，然后返回第一個(gè)參數(shù)的值，所以auto _Pnext = _STD exchange(_Myproxy->_Myfirstiter, nullptr)可以理解為：

_Pnext = _Myproxy->_Myfirstiter；

_Myproxy->_Myfirstiter = nullptr；

上述只是簡(jiǎn)單理解這個(gè)函數(shù)的功能，這樣看這里也沒有問題

到了這里我們還是無法知道_Pnext指向的區(qū)域?yàn)槭裁醋兂煞欠ǖ?#xff0c;還有就是_Pnext到底指向的是什么，也就是它到底是什么，怎么來的，于是根據(jù)發(fā)生異常的調(diào)用棧進(jìn)一步追蹤，看一下具體是怎么發(fā)生的。根據(jù)調(diào)用棧我們看到了一個(gè)明顯的可能有問題的地方那就是std::string::~basic_string()，這里先猜測(cè)string對(duì)象析構(gòu)的時(shí)候發(fā)生了異常，析構(gòu)的時(shí)候一般會(huì)去釋放資源，是不是釋放的資源出來問題，所以才導(dǎo)致的異常。

bool EncodedDescriptorDatabase::DescriptorIndex::AddSymbol(absl::string_view symbol) {SymbolEntry entry = {static_cast<int>(all_values_.size() - 1),EncodeString(symbol)};std::string entry_as_string = entry.AsString(*this);// We need to make sure not to violate our map invariant.// If the symbol name is invalid it could break our lookup algorithm (which// relies on the fact that '.' sorts before all other characters that are// valid in symbol names).if (!ValidateSymbolName(symbol)) {ABSL_LOG(ERROR) << "Invalid symbol name: " << entry_as_string;return false;}auto iter = FindLastLessOrEqual(&by_symbol_, entry);if (!CheckForMutualSubsymbols(entry_as_string, &iter, by_symbol_.end(),*this)) {return false;}// Same, but on by_symbol_flat_auto flat_iter =FindLastLessOrEqual(&by_symbol_flat_, entry, by_symbol_.key_comp());if (!CheckForMutualSubsymbols(entry_as_string, &flat_iter,by_symbol_flat_.end(), *this)) {return false;}// OK, no conflicts.// Insert the new symbol using the iterator as a hint, the new entry will// appear immediately before the one the iterator is pointing at.by_symbol_.insert(iter, entry);return true;
}

于是繼續(xù)追蹤代碼里面是哪個(gè)執(zhí)行造成的，還是根據(jù)前面的調(diào)用棧，我們看到執(zhí)行完AddSymbol后，會(huì)調(diào)用~basic_string()，那么根據(jù)上面的代碼來看，應(yīng)該是entry_as_string這個(gè)對(duì)象的使用有問題。

根據(jù)debug信息，看到entry_as_string的內(nèi)存有問題，到這來還不知道是因?yàn)楸会尫帕?#xff0c;還是本身創(chuàng)建出來的就有問題，繼續(xù)追蹤這個(gè)是怎么創(chuàng)建出來的。

std::string AsString(const DescriptorIndex& index) const {auto p = package(index);return absl::StrCat(p, p.empty() ? "" : ".", symbol(index));}

std::string StrCat(const AlphaNum& a, const AlphaNum& b, const AlphaNum& c) {std::string result;// Use uint64_t to prevent size_t overflow. We assume it is not possible for// in memory strings to overflow a uint64_t.constexpr uint64_t kMaxSize = uint64_t{std::numeric_limits<size_t>::max()};const uint64_t result_size = static_cast<uint64_t>(a.size()) +static_cast<uint64_t>(b.size()) +static_cast<uint64_t>(c.size());ABSL_INTERNAL_CHECK(result_size <= kMaxSize, "size_t overflow");strings_internal::STLStringResizeUninitialized(&result, static_cast<size_t>(result_size));char* const begin = &result[0];char* out = begin;out = Append(out, a);out = Append(out, b);out = Append(out, c);assert(out == begin + result.size());return result;
}

這里重點(diǎn)是std::string result；這個(gè)result有問題，但是有實(shí)在看不出代碼哪里有問題，于是只能繼續(xù)debug，進(jìn)入這個(gè)函數(shù)后一步步運(yùn)行，看一下具體是哪里出了問題。

在運(yùn)行的過程中，這個(gè)result的就沒有顯示出來，它的內(nèi)存是什么，指向哪里根本不知道。

只知道這個(gè)函數(shù)返回的時(shí)候，entry_as_string指向了一個(gè)錯(cuò)誤的內(nèi)存，最終導(dǎo)致崩潰，目前從debug的過程來看不出具體是什么原因?qū)е碌膯栴}。

于是寫了一段類似的測(cè)試代碼，看看能不能復(fù)現(xiàn)到這樣的問題，也可以對(duì)比這個(gè)過程中有哪些不一樣，看看能不能找出根本原因。

測(cè)試代碼在運(yùn)行的過程中沒有出錯(cuò)，只能看到它們不一樣的地方

	異常代碼	測(cè)試代碼
1	std::string result 沒有跑構(gòu)造函數(shù)	std::string result 正常跑構(gòu)造函數(shù)
2	debug過程沒有顯示result的信息	debug過程會(huì)顯示result的信息
3	函數(shù)里面的begin、out等變量也沒有信息	函數(shù)里面的begin指向和顯示沒有問題

目前猜測(cè)可能是std::string StrCat(const AlphaNum& a, const AlphaNum& b, const AlphaNum& c) 函數(shù)里面的代碼被優(yōu)化了導(dǎo)致的。