不少朋友在使用UE4/UE5時(shí)，都有遇到崩潰和卡機(jī)的問(wèn)題，大數(shù)情況下，可能都不知如何解決，渲云小編來(lái)分析了一些經(jīng)驗(yàn)技巧，該如何解決呢？具體來(lái)看下面的介紹操作。

一、常規(guī)崩潰定位

當(dāng)游戲崩潰時(shí)，開(kāi)發(fā)者必須想要定位哪一行代碼崩潰了，以及崩潰發(fā)生時(shí)內(nèi)存是什么。在錯(cuò)覺(jué)引擎中，這項(xiàng)工作是由引擎自動(dòng)完成的。引擎會(huì)將崩潰的轉(zhuǎn)儲(chǔ)文件保存在Saved/ crash下。編輯器的位置。

游戲包在運(yùn)行時(shí)的位置是相似的。PC版本在游戲目錄下，Android版本在Android/data/(游戲包名)/下，iOS版本在應(yīng)用對(duì)應(yīng)的Documents目錄下。當(dāng)出現(xiàn)多次崩潰時(shí)，可以按修改日期排序，找到最新的一次。

打開(kāi)后你可以看到很多信息。

Dmp文件：文件崩潰的轉(zhuǎn)儲(chǔ)信息。您可以直接將文件拖到visual studio，它將自動(dòng)跳轉(zhuǎn)到崩潰站點(diǎn)的代碼行。

Log文件：該文件是崩潰時(shí)的日志信息。您可以根據(jù)打印的日志做出一些崩潰輔助判斷。例如，在崩潰之前執(zhí)行了哪些關(guān)鍵操作。

runtime-xml文件：該文件以文本形式記錄崩潰場(chǎng)景，包括堆棧、崩潰代碼等。它本質(zhì)上類似于dmp文件，因?yàn)閐mp是一個(gè)不可讀的二進(jìn)制文件。當(dāng)手邊沒(méi)有符號(hào)文件時(shí)，可以使用該文件分析崩潰。

在理解了引擎的這一功能后，可以定位80%的碰撞。就像最常見(jiàn)的Signal 11一樣，我們可以初步找到場(chǎng)景的位置。

二、卡死檢測(cè)

有時(shí)根據(jù)墜機(jī)現(xiàn)場(chǎng)很難找出墜機(jī)的原因。我們希望在一些關(guān)鍵位置輸出堆棧或內(nèi)存信息?；蛘咚灰欢ㄊ潜罎ⅲ且粋€(gè)無(wú)休止的循環(huán)卡住了，所以一定沒(méi)有如上所述的轉(zhuǎn)儲(chǔ)信息輸出。引擎連接到Lua或其他腳本語(yǔ)言。當(dāng)腳本出現(xiàn)異常時(shí)，您還必須希望輸出c++堆棧。因此，我絕對(duì)希望我能找到一些方法在代碼中輸出當(dāng)前堆棧。該引擎也提供了這樣的方法。參見(jiàn)StackWalk類

有一系列的函數(shù)。例如，可以使用StackWalkAndDump函數(shù)將當(dāng)前堆棧輸出為字符串。當(dāng)然，如果它不是GameThread，這個(gè)類也為轉(zhuǎn)儲(chǔ)指定的線程提供一個(gè)堆棧。例如，lua腳本中的代碼崩潰，但由于lua的崩潰有一個(gè)通用函數(shù)，c++不會(huì)直接崩潰。我們可以手動(dòng)調(diào)用這樣的函數(shù)，將c++堆棧寫入Log。

為了解決業(yè)務(wù)問(wèn)題，虛幻引擎還封裝了一個(gè)單獨(dú)的守護(hù)進(jìn)程線程ThreadHeartBeat。當(dāng)檢測(cè)到線程的心跳超過(guò)時(shí)間限制時(shí)，還會(huì)在內(nèi)部調(diào)用上面的函數(shù)，將卡住的線程堆棧輸出到Log中。

自己的業(yè)務(wù)也可以根據(jù)上述實(shí)踐進(jìn)行封裝。該功能默認(rèn)關(guān)閉。畢竟，有額外線程的成本。項(xiàng)目需要使用USE_ HANG_ The DETECTION宏打開(kāi)。

三、內(nèi)存隨機(jī)損壞或泄漏

內(nèi)存損壞和隨機(jī)程序崩潰問(wèn)題是大多數(shù)項(xiàng)目中最麻煩的問(wèn)題。事實(shí)上，虛幻的底層還提供了一些定位代碼來(lái)解決這些問(wèn)題。因?yàn)檫@是一個(gè)內(nèi)存問(wèn)題，所以這些工具代碼也適用于內(nèi)存。

在全局重載的c++中，illusion本身有new和delete。當(dāng)業(yè)務(wù)分配和釋放內(nèi)存時(shí)，實(shí)際上會(huì)調(diào)用引擎的FMemory類中的Malloc和Free。引擎會(huì)根據(jù)情況從內(nèi)存池中獲取內(nèi)存。引擎使用內(nèi)存池本身的內(nèi)存根據(jù)定時(shí)向系統(tǒng)請(qǐng)求內(nèi)存。如果你使用引擎的LLM來(lái)計(jì)算內(nèi)存，你應(yīng)該知道LLM有兩個(gè)跟蹤器，默認(rèn)和平臺(tái)。這兩個(gè)維度還對(duì)應(yīng)于兩種情況：業(yè)務(wù)需要來(lái)自引擎的內(nèi)存，而引擎需要來(lái)自操作系統(tǒng)的內(nèi)存。

LLM Default和LLM Platform的關(guān)系如下圖所示。由于這種機(jī)制，我們總是說(shuō)UE4/UE5項(xiàng)目不使用STL。因?yàn)镾TL有自己的分配器，當(dāng)沒(méi)有指定分配器時(shí)，所有的內(nèi)存分配都不由引擎管理，而且因?yàn)镾TL本身只有頭文件，即使顯式指定了分配器，在跨dll使用時(shí)可能會(huì)由于疏忽而導(dǎo)致一些內(nèi)存問(wèn)題。

這里的關(guān)鍵點(diǎn)是FMemory可以在內(nèi)部使用多個(gè)分配器，而且有些分配器可以嵌套，這對(duì)上層業(yè)務(wù)不敏感。引擎通常默認(rèn)使用binne2或Binned3，內(nèi)部?jī)?nèi)存池將根據(jù)大小制作。當(dāng)內(nèi)存池不足時(shí)，每次向系統(tǒng)應(yīng)用固定大小的Chunk。由于本文的重點(diǎn)不是內(nèi)存管理和LLM，因此不進(jìn)行擴(kuò)展。

要檢查內(nèi)存損壞，需要在這里打開(kāi)一些特殊的分配器。最常用的有以下幾種：

Ansi：這是一個(gè)標(biāo)準(zhǔn)的分配器，這意味著UE4不使用任何額外的內(nèi)存管理，而是直接使用平臺(tái)的本機(jī)new和delete。有時(shí)它需要使用一些平臺(tái)的內(nèi)存工具。這個(gè)模式很好。例如，在iOS平臺(tái)上，需要檢查內(nèi)存泄漏。如果你使用默認(rèn)的binne2 /Binned3，你不能用Xcode的內(nèi)置工具找到泄漏的具體代碼。您所看到的就是正在申請(qǐng)內(nèi)存池，并且當(dāng)您驅(qū)動(dòng)到Ansi時(shí)，您可以定位內(nèi)存泄漏字段。

Stomp：這是引擎提供的檢查內(nèi)存損壞的強(qiáng)大工具。一般情況下，啟用該模式。崩潰的第一個(gè)場(chǎng)景是編寫代碼的位置。具體原理是利用操作系統(tǒng)的虛擬地址概念。我們知道，當(dāng)我們向系統(tǒng)請(qǐng)求內(nèi)存時(shí)，我們得到的指針實(shí)際上是一個(gè)虛擬地址。是否真正分配了物理內(nèi)存取決于具體情況。如何解決這些問(wèn)題，請(qǐng)參考下面的說(shuō)明

在這種模式下，每次內(nèi)存分配的指針地址只會(huì)增加，而不會(huì)減少。實(shí)際使用的內(nèi)存將要求系統(tǒng)分配相應(yīng)的物理內(nèi)存。當(dāng)需要釋放已使用的內(nèi)存時(shí)，只取消虛擬地址與物理內(nèi)存的映射關(guān)系，相應(yīng)的虛擬地址不會(huì)被回收。因?yàn)檫@些操作非常特殊，所以不能直接使用malloc等函數(shù)從系統(tǒng)請(qǐng)求內(nèi)存。Windows使用VirtualAlloc函數(shù)，其他平臺(tái)使用mmap函數(shù)?；厥諘r(shí)，Windows使用VirtualFree，其他平臺(tái)使用munmap功能。

隨機(jī)崩潰的內(nèi)存寫失敗基本上是因?yàn)楸罎r(shí)間不是第一個(gè)場(chǎng)景。在正常模式下，第一個(gè)場(chǎng)景有很大概率是正常內(nèi)存，因?yàn)閮?nèi)存本身是合法的，不會(huì)塌縮，但是正常內(nèi)存中的數(shù)據(jù)寫的不好。在Stomp模式下，地址只會(huì)增加而不會(huì)減少，也不會(huì)被重用。只要寫入不應(yīng)該寫入的內(nèi)存，比如那些在回收后只有虛擬地址的指針，就會(huì)在第一時(shí)間崩潰。UE5還提供了在運(yùn)行時(shí)可以通過(guò)命令行stomp2malloc打開(kāi)Stomp2。

PoisonProxy：這個(gè)模式，顧名思義，用毒藥涂抹內(nèi)存。它主要解決不使用未初始化或空閑內(nèi)存的問(wèn)題，如下面的說(shuō)明所述。

其原理是在分配或釋放后，通過(guò)Memset將以下魔法代碼填滿內(nèi)存

老程序員應(yīng)該對(duì)0xcd、0xcc和0xdd的值印象深刻。畢竟，Windows也做同樣的事情。一堆0xcccc的GBK Chinese很熱，0xcdcd的GBK Chinese也很熱。當(dāng)崩潰發(fā)生時(shí)，將顯示這樣的地址。你可以根據(jù)0xcc和0xcd來(lái)判斷釋放的內(nèi)存是否沒(méi)有初始化或被使用，這樣你就可以定位代碼出現(xiàn)問(wèn)題的第一個(gè)場(chǎng)景。

ReplayProxy：用來(lái)記錄分配給文件的內(nèi)存。有時(shí)檢查一些性能問(wèn)題可能是有用的。

當(dāng)然，除此之外，您還可以使用一些外部工具來(lái)檢查內(nèi)存問(wèn)題，比如最常用的ASan。

四、減少由野指針引起的崩潰的技巧

當(dāng)引擎判斷UObject是否合法時(shí)，它提供了基于編程經(jīng)驗(yàn)或指針特征來(lái)檢測(cè)野指針的想法，我們也可以參考，例如IsValidLowLevelFast。

你可以看到上面三個(gè)if的代碼非常有趣。如果這是一個(gè)合法的對(duì)象，那么指針不能為空ptr或小于0x100，指針值必須是8的倍數(shù)，并且指針，即虛函數(shù)表，不能為空ptr。仔細(xì)想想，普通Object對(duì)象的指針確實(shí)需要滿足這些條件。小于0x100的指針通常在系統(tǒng)內(nèi)部使用。系統(tǒng)按照字節(jié)對(duì)齊的方式分配內(nèi)存，所以它必須是8的倍數(shù)。經(jīng)過(guò)這樣的經(jīng)驗(yàn)，基本排除了超過(guò)七分之八的野指針，所以我也建議將這種判斷方法擴(kuò)展到業(yè)務(wù)上使用。

渲云影視動(dòng)畫支持maya、3ds max 、C4D、Houdini、Clarisse、Katana、Keyshot、Blender、Vred等。以UE渲染來(lái)說(shuō)，高量高速，海量GPU資源，目前渲云平臺(tái)是業(yè)內(nèi)獨(dú)家支持UE渲染。渲染過(guò)程中，支持實(shí)時(shí)預(yù)覽。

解決由于本地配置不足引起的UE渲染慢和渲染卡頓等問(wèn)題，速度更快，效率更高。

海量GPU資源

強(qiáng)大的公有云資源配置，GPU節(jié)點(diǎn)彈性擴(kuò)展，服務(wù)器規(guī)格靈活調(diào)配，可一鍵加載各種渲染環(huán)境，滿足各種渲染任務(wù)執(zhí)行。