我如何調查啟動應用程序時發生的訪問沖突的來源？

Question

我是C ++編程的新手。 我正在編譯一個Windows應用程序，該應用程序僅帶有幾個警告就可以編譯，但是當我啟動它時，它似乎沒有啟動，並在運行3秒后返回了訪問沖突。 當我嘗試調試時，它似乎甚至都沒有涉足代碼，因此我不知道從哪里開始尋找問題。

這是我已經能夠從調試器中檢索的信息：

Building to ensure sources are up-to-date
Build succeeded
Selecting target: 
Debug
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding source dir: C:\Documents and Settings\Christian Ekiza\Mis documentos\My Dropbox\Private Files\coding\juego_pruebas_01\juego_pruebas_01\
Adding file: bin\Debug\juego_pruebas_01.exe
Starting debugger: 
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 3328
Program received signal SIGSEGV, Segmentation fault.
In ?? () ()

這是來自調用堆棧

#0 00000000 0x000154e4 in ??() (??:??)
#1 00409198 __cmshared_create_or_grab() (../../../../gcc-4.4.1/libgcc/../gcc/config/i386/cygming-shared-data.c:140)
#2 00000000 0x0040131b in __gcc_register_frame() (??:??)
#3 00000000 0x0040a09b in register_frame_ctor() (??:??)
#4 00000000 0x00408f42 in __do_global_ctors() (??:??)
#5 00000000 0x00401095 in __mingw_CRTStartup() (??:??)
#6 00000000 0x00401148 in mainCRTStartup() (??:??)

並且CPU寄存器以

'gs' register with a hex value '0x0'

我真的不知道從哪里開始尋找問題。 任何人都可以幫助我或為我指明正確的方向嗎？

注意：我正在使用Code :: Blocks

Answer 1

正如您所說的，它是Windows應用程序。 然后，任何有關啟動的問題，我都發現ADPlus非常有用。

編輯2：

如果ADPlus不適用，您還可以檢查用戶模式進程轉儲程序

Answer 2

看，如果您有一些帶有構造函數的類的全局實例-如果構造函數中引發了錯誤，並且全局聲明了類（這樣做不好），那么即使在main（）之前，您也會得到sigsegv。 如果您有這樣的類-嘗試重構代碼以將它們包含在main（或其他函數）中-則調試起來會更容易。

Answer 3

嘗試使用以下免費的MS工具-都非常適合調試此類問題。

• 應用程序驗證程序http://www.microsoft.com/downloads/zh-CN/details.aspx?familyid=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en

• Windows調試工具中的Gflags http://www.microsoft.com/downloads/zh-cn/details.aspx?FamilyID=6b6c21d2-2006-4afa-9702-529fa782d63b&displaylang=en

Answer 4

在我看來，您的DLL依賴項之一無法正確加載或實例化。

Answer 5

您是否在啟用調試模式（ -g ）的情況下進行編譯？

還應認真考慮實際糾正警告。 在大多數情況下，它們是應解決的代碼中的實際問題。

您還應該嘗試查看這種情況是否在幾乎為空的main中發生（在main注釋掉大部分/全部代碼）。