大型c++項目在linux下如何調試?

好吧,確實有點黑linux的意思.

不過也好奇怪c++在linux下沒有可視化的IDE調試環境, 怎麼調試的呢?

ps: 如果沒有真正做過(參與過)就不要意淫啦.

---

shell+vim+git+find+grep+收log，就這麼幾板斧，幾十人維護數百萬行code妥妥的。

---

gdb比你想像的好使。

---

邏輯錯誤用log，內存錯誤用gdb，單元測試用gtest，編譯器用clang，log框架用log4cplus，性能熱點用gprof，這樣就沒有搞不定的bug

補充一條，內存錯誤用valgrind，但我一直覺得習慣良好的C++代碼永遠不會犯內存錯誤

---

我只是在評論裡面說了一句，IDE的可視化比GDB好用。就被在生產環境下去掛GDB調試，並且不知道IDE可以掛遠程調試的牛人噴了菜鳥。冏

------------------------------------------------------------

首先，linux沒有可視化的IDE調試環境是錯誤的。IDE還是很多的，eclipse ,codewarrior等等，只是有沒有微軟的VS好用，那就各有各的看法了。:)

--------------------------------------------------------------

以我端游伺服器的經驗來看：

一般都是跨平台開發，底層IO封裝好後，上層代碼基本上都和底層無關。這個時候使用VS開發，大部分bug也是使用VS調試。畢竟對於一般程序員來說，VS的開發效率和調試效率比linux下高太多了，而且大部分程序員的代碼也和底層無關。

在項目上線測試後，邏輯bug通過log定位，crash的查看core dump。一般來說與底層無關的代碼出問題，還是會在重現bug後，使用VS調試。

上線後的有些bug會很痛苦，因為log很可能沒有覆蓋到bug出現的場景，只能猜測大概產生原因，甚至連大概原因都沒法猜測。。。所以有時候還會實現一些特殊的模塊會輔助調試，比如記錄所有IO輸入，在dump後回放以重現bug。

---

該怎麼調試就怎麼調試，毫無壓力。 XD

一、命令行在伺服器開發中具有巨大優勢

題主的疑問還是可以理解的，從直觀上感受命令行有一種望而生畏的感覺。現在的電腦用戶大都是從Windows開始用起的，對在黑屏幕上敲代碼有一種天生的抵觸。

但是這真的不是全部的事實，事實上：

1. 命令行真的非常好用，一點都不比圖形界面差。很多時候複雜操作用shell遠好於用滑鼠點點點……
2. 伺服器開發，Coding用不用IDE看個人喜好（因為不帶GUI，不需要看外觀效果）。
3. Debug方面，其實掛在生產環境下調試時，或者查看coredump時，IDE一點也不好用！這種情況下gdb是最穩妥最方便最容易找到問題的。
4. 工作中必須用圖形界面的是瀏覽器（這個用控制台真不行，哈哈）。
5. 在開發、生產、測試環境下用同一種操作方法真的很爽，在不同操作系統之間切換才最讓人感覺到心累。
6. Linux下開發者主要有三種人：用IDE編碼和調試；用IDE編碼、用GDB調試；用VIM或其他編碼、用GDB調試。無論哪種人，都必須掌握GDB調試以應對生產伺服器上面的BUG。

二、圖形界面在運維和開發中優勢很小

Windows對伺服器開發、運維人員來說真沒什麼好感。我們大部分人覺著Windows好用，是因為我們是消費者用戶，對運維人員來講，每天面對的是類似這種界面：

還有這種：

說實話，看的行數多了狗眼都瞎了。遠沒有Linux上的配置文件來的易於複製、查找。

當然Linux運維相關的資料多，Windows資料少，也是一大重要原因。

三、關於調試

Debug有兩層意思，狹義的Debug指通過gdb等工具進行斷點分析，廣義的debug是分析程序的過程。

如果是開發客戶端程序，我還是很推崇IDE的。用控制台調試帶界面的程序……很不自然。

如果是伺服器相關開發，其實斷點分析只佔所有Debug過程的一小部分。因為：很多很多時候，伺服器是面對多位用戶的，你不能把伺服器程序中斷下來；而且還有相當一部分的BUG是存在於不確定的狀態下，你很難確定打斷點的時機。這個時候Log分析、源碼分析、Coredump分析都遠比斷點調試好用得多。這時候你就知道GDB的功能多麼強大了。

---

總之寫了這麼多，我想說這個世界我們真的只能理解一個角落。看不懂的東西太多了，比如我就看不懂為什麼大部分人在股票市場上都在賠錢，還仍然樂此不疲地投入，而且國家還保護這種扔錢的行為，哈哈。

只是面對自己不熟悉的領域，不要拿自己的知識生硬地往上面套，然後得出「XXX不如YYY」的結論。記住這世界上，正好有另一批自大的人也在得出「YYY不如XXX」的結論。

---

這個問題我應該有資格回答你，因為參與過幾千萬的高可用高要求的關鍵核心項目（銀行系統+跨國團隊），數百人年的項目。

如何調試？

說出來別不信，log，基本上調試版每行代碼都會列印一條log。然後有log分析系統。

可能有人會用gdb，但多數人都是看log。

不過項目不是C++，而是純C，C++太複雜可能不適合這麼干。。。oh my god！

---

原來在一家公司做信令網關，軟交換的，基本框架和 sipX 很類似，算是大型 C++ 項目了。開發的話，有 IDE，kdeveloper 還是可以的，用不習慣的使用 vim 一樣的高效。調試的話，使用 unittest，另外是 gdb，gdb 的很多高階邪門兒用法就是那個時候玩兒出來的。內存分析用 valgrind。網路抓包用 etheral，現在叫 wireshark，再不行就 tcpdump。linux 下可視化工具不多，但是雜七雜八的工具多，吐啊吐啊就習慣了。

---

我一般用 cgdb，還有 log，偶爾用 CLion。

---

紅帽工程師開發的insight好像不更新了，我就把DDD裝上了。正好最近要寫個詞法分析器，雖然不是大項目，但也正好用用makefile和DDD。另外，還有個叫kdbg，不過我沒裝kde環境，所以沒用它。好像還有個叫xxgdb，當然還有其他的。

---

Linux 有IDE啊 Qt 之類的 還是挺方便的

而且也不少 現在大部分IDE都是跨平台的

當然不如VS這種 但是總比xcode好。。

為黑而黑，有點沒意思

==============

隨手加一句，大型項目print之類的肯定不好使 GDB 感覺有點點麻煩(不過可能我研究的不夠) log我真的不清楚。個人還是比較傾向於 IDE的。

---

1.開發機

方案一: 裝一個xfce桌面加clion，使用vnc直接開發+調試

方案二: 安裝remote gdb，開放調試埠，windows上使用clion attach上去(需要自己編譯gdb，此外vscode和vs的remote debug都是殘的)

2.線上環境

直接gdb（僅限 Core Dump）

更多時候看的log來定位問題

---

linux上的調試比不上windows上那麼方便（不說功能是否強大，便利性是肯定有差距的）

好在有萬能的日誌手段來調試

win下的dbgview很好用，linux上就只好打在命令行上了。太不方便了於是我做了一個linux上遠程將調試信息輸出到win端的庫。。

---

弱弱的問一句為什麼要用IDE調試？ 大型網路項目，幾十個廠家合作，我們的方法是gdb，core文件，tcpdump，valgrind，vim+各種正則表達式+完善的log，依靠這些工具調試完全能hold住啊，想想這個項目用IDE還是挺奇怪的啊。。還是不懂為什麼要用IDE。。沒用過IDE調試大型項目，求解釋。。

----------------------------------------------------------------------------

可能我的回答產生了歧義，我只是針對樓主的問題，條件反射的利用反問來諷刺下。。

其實我支持在特定場景下使用最適合的工具去開發。。

---

這幾天一直在做java開發，發現intelij進行java的遠程debug，再配合上svn簡直爽翻了，只要寫好腳本，工作起來就像在本機編譯運行一樣。

對於Cpp，後來發現有gdbserver這樣的東西，開始考慮用codeblocks或者vs裝一個windb和svn插件（可惜要收費）試一試。

利益相關：lldb粉 gdb黑

---

簡單說，很難，累成狗。

有一些系統，你甚至不敢把gdb掛上去。因為稍微長一點的等待都會觸發各個不同層次的超時，看門狗， HA等機制，直接導致進程panic。

你根本也沒機會使用valgrind這類的東西，因為這個進程會載入幾百個模塊，而且有些模塊的二進位文件大小就是幾百兆位元組。

調試core文件也不是玩的，你能想像嘗試分析一個有超過9K個線程的巨大進程嗎？試圖列印全部線程的call stack需要的時間以幾十分鐘記。對了，忘了說，一個解壓的core文件的大小一般也只有20來G的樣子。

系統從一開始也許是好的，但是架構加了一層又一層。簡單地說，windows內核模塊直接運行在linux用戶態進程中。差不多就是這個樣子。

IDE？我們不知道有這個辭彙！

gdb？我們需要的是專門開發專門的擴展，支持windbg的指令。gdb對C++的支持太爛，我們只使用log，各個層次的log。

valgrind？能支持運行時掛載才行，不行就算了。

這樣的系統，編譯一下怎麼也得半小時吧？半小時編譯只是比如修改幾行行代碼的時候差不多的時間。整個系統編譯大約要7個小時，現在快多了，只有三個半小時。

回歸測試也只需要幾個小時而已！

幾乎所有的傳統linux工具scale out的能力接近於渣。

---

1. 用gdb 調試，絕對沒有你想像的那麼難用。

2. 大系統一般會備有完善的LOG系統和動態調節的配置。這足以應對一般的邏輯問題了。我們用的是 log4cplus/log4cplus · GitHub。

上面有人說，emacs + gdb ，的確非常 nice。恰好我是用 Emacs 做開發。如下圖：

基本上和IDE差不了多少了。但是，我很少用，因為太慢了，扛不住。

以前我用 VS2010 做開發，今年轉到伺服器開發。剛做的時候感覺不適應，後來慢慢就習慣了。不管是你說的大項目還是一般的項目（大項目也是有小模塊堆積而成），平時用的基本上不會特別複雜，最多也不過線程堆棧切換而已。

---

想當初寫linux程序，都是用跨平台庫，在windows上調完了再丟linux上去……逃）

---

等clion吧，你要相信jetbrains的實力哈哈哈。clion已經有EAP可以下了。

---

裝X，然後就可以用Eclipse了。不過如果是跨平台代碼的話，你現在Windows下搞好，然後到Linux下面跑unittest，事半功倍。

---

我不知道有一部分linux粉是怎麼想的。

明明ide調試就是方便，工具調試就是麻煩。

是，你們是高大上，聰明，厲害，天下無敵，舉世無雙，所以學會了使用各種命令行和奇奇怪怪的文本編輯器來做一般人做不到的事情。好極了，棒極了，屌炸天。

工具不難用到極點，怎麼能體現掌握這些工具的你們的高大上呢？

缺點就是缺點，像其他很多答案一樣客觀評價下缺點和面對缺點要怎麼辦很難？

腦殘粉真是全世界第二low的群體，第一low的勉強讓給腦殘黑好了。

---------------------------------------------------------------------------------------------------------------

噴傻逼的說完了，我們來說說正題。

linux缺少優秀的ide是真的，不好用，但是有時候你必須要用。

所謂逼上梁山，一條路不是你不想走就可以不走的。所以你必須去找很多printf和gdb的調試技巧，找很多linux桌面系統的配置技巧，和eclipse等等工具的配置技巧。

是的，linux非常不好用。但是他有他的優點。當你需要linux這樣一個操作系統的時候，你必須面對他缺少可以商業化那樣優秀的ide的支持這個殘酷的現實。

你深刻明白一點：你需要會更多地工具更多的技術，然後在最合適的時候使用最合適的技術。

而不是因為windows好調試選擇windows。你要看到的是，選擇了windows以後方方面面的問題。譬如維護成本。是的，人力成本超便宜了，但是一個伺服器的價格。。我不了解，反正當年我說要用windows做伺服器的時候被老闆罵得要死要活的。當時我的確不如一個windows值錢啊。

---

推薦閱讀：