散文網(wǎng) » 游戲 »網(wǎng)絡(luò)游戲 » 讓我們?cè)偕钊胍稽c(diǎn)...，理解Minecraft崩潰日志還不至于這么難！

讓我們?cè)偕钊胍稽c(diǎn)...，理解Minecraft崩潰日志還不至于這么難！

2023-06-14 16:57 作者:北葵Starry 0人讀過 | 我要投稿

這是第一篇總結(jié)性的修復(fù)崩潰的解決方案，以下是第二篇，算是進(jìn)階版。

我一直有打算寫更深層次的修復(fù)崩潰的解決方案（出于版本更新，以及運(yùn)作方式的更新沒錯(cuò)我就是說Fabric的橫空出世等緣故），但一提到更深層次，估計(jì)也不少人會(huì)頭疼？不過我會(huì)盡可能地給大家解釋好的！(那么，不說廢話，我們就跳進(jìn)主題?。?！

我對(duì)代碼并非特別了解w，是積累的經(jīng)驗(yàn)寫出來得啦，如果有什么東西我解釋錯(cuò)了，也煩請(qǐng)告知我修改或者在評(píng)論區(qū)補(bǔ)充喵~

一、日志

查看日志，全英的對(duì)吧(，所以想要深入看日志，英語應(yīng)該得行，能理解意思，而不能完全相信機(jī)器翻譯給你的意思（也并非不讓你去用喵），它們還理解不了我的世界的一些特別的術(shù)語。在下面的演示中，為了方便你理解一些崩潰日志里的一些東西，我會(huì)附帶翻譯上去哦~

但是，這并不意味著你不能跳過這個(gè)門檻，我們的標(biāo)題叫做再深入一點(diǎn)，并非讓你深入到全英的代碼結(jié)構(gòu)去分析的啦！日志本身還突出了一些能讓我們發(fā)現(xiàn)幕后黑手的痕跡，來讓我們看看吧~

（感謝群里的群友上傳的一個(gè)崩潰日志，這里就拿來用啦w）

---- Minecraft Crash Report ----

// Shall we play a game?

Time: 2022/12/10 下午10:30

Description: Rendering entity in world

（在舊版本中，這個(gè)位置還會(huì)有Caused by:（導(dǎo)致原因））java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0

at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading}

at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading}

at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading}

at java.util.Objects.checkIndex(Objects.java:372) ~[?:?] {}

at java.util.ArrayList.get(ArrayList.java:459) ~[?:?] {}

at com.lootbeams.LootBeamRenderer.getRawColor(LootBeamRenderer.java:217) ~[lootbeams:1.16.5-release] {re:classloading}

at com.lootbeams.LootBeamRenderer.getItemColor(LootBeamRenderer.java:191) ~[lootbeams:1.16.5-release] {re:classloading}

at com.lootbeams.LootBeamRenderer.renderLootBeam(LootBeamRenderer.java:54) ~[lootbeams:1.16.5-release] {re:classloading}

at com.lootbeams.ClientSetup.onRenderNameplate(ClientSetup.java:59) ~[lootbeams:1.16.5-release] {re:classloading}

at net.minecraftforge.eventbus.EventBus.doCastFilter(EventBus.java:247) ~[eventbus-4.0.0.jar:?] {}

at net.minecraftforge.eventbus.EventBus.lambda$addListener$11(EventBus.java:239) ~[eventbus-4.0.0.jar:?] {}

at net.minecraftforge.eventbus.EventBus.post(EventBus.java:302) ~[eventbus-4.0.0.jar:?] {}

at net.minecraftforge.eventbus.EventBus.post(EventBus.java:283) ~[eventbus-4.0.0.jar:?] {}

at jdk.internal.reflect.GeneratedMethodAccessor67.invoke(Unknown Source) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading,re:classloading,re:classloading,re:classloading,re:classloading}

at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?] {re:classloading}

at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?] {}

at net.optifine.reflect.Reflector.call(Reflector.java:1144) ~[?:?] {re:classloading}

at net.optifine.reflect.Reflector.postForgeBusEvent(Reflector.java:1417) ~[?:?] {re:classloading}

at net.minecraft.client.renderer.entity.EntityRenderer.func_225623_a_(EntityRenderer.java:96) ~[?:?] {re:mixin,pl:accesstransformer:B,xf:OptiFine:default,re:classloading,pl:accesstransformer:B,xf:OptiFine:default,pl:mixin:APP:entityculling.mixins.json:EntityRendererMixin,pl:mixin:A}

at net.minecraft.client.renderer.entity.ItemRenderer.func_225623_a_(ItemRenderer.java:124) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:fml:itemphysic:renderer}

at net.minecraft.client.renderer.entity.ItemRenderer.func_225623_a_(ItemRenderer.java:18) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:fml:itemphysic:renderer}

...[省略]...

at cpw.mods.modlauncher.Launcher.main(Launcher.java:66) [modlauncher-8.1.3.jar:?] {re:classloading}

A detailed walkthrough of the error, its code path and all known details is as follows:

（以下是對(duì)該錯(cuò)誤、其代碼路徑以及所有已知細(xì)節(jié)的詳細(xì)清單：）

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

-- Head --

Thread: Render thread

Stacktrace:

at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading,re:classloading}

at jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70) ~[?:?] {re:classloading,re:classloading,re:classloading,re:classloading,re:classloading}

...[省略]...

at net.minecraft.client.renderer.entity.ItemRenderer.func_225623_a_(ItemRenderer.java:18) ~[?:?] {re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:fml:itemphysic:renderer}

-- Entity being rendered --

Details:

Entity Type: minecraft:item (net.minecraft.entity.item.ItemEntity)

Entity ID: 85

Entity Name: item.tetra.modular_double

Entity's Exact location: 454.34, 104.69, 3882.46

Entity's Block location: World: (454,104,3882), Chunk: (at 6,6,10 in 28,242; contains blocks 448,0,3872 to 463,255,3887), Region: (0,7; contains chunks 0,224 to 31,255, blocks 0,0,3584 to 511,255,4095)

Entity's Momentum: -0.29, -0.05, -0.01

Entity's Passengers: []

Entity's Vehicle: ~~ERROR~~ NullPointerException: null

-- Renderer details --

Details:

Assigned renderer: net.minecraft.client.renderer.entity.ItemRenderer@6e8f1e

...[省略]...

nui-forge.json:AccessGameRenderer,pl:mixin:A}

-- Affected level --

Details:

All players: 1 total; [ClientPlayerEntity['LaoYi'/82, l='ClientLevel', x=454.34, y=103.38, z=3882.46]]

Chunk stats: Client Chunk Cache: 5041, 121

...[省略]...

Server type: Integrated singleplayer server

Stacktrace:

at net.minecraft.client.world.ClientWorld.func_72914_a(ClientWorld.java:617) ~[?:?] {re:mixin,pl:accesstransformer:B,xf:OptiFine:default,xf:fml:xaerominimap:xaero_clientworldclass,xf:fml:xaeroworldmap:xaero_wm_clientworldclass,re:classloading,pl:accesstransformer:B,xf:OptiFine:default,xf:fml:xaerominimap:xaero_clientworldclass,xf:fml:xaeroworldmap:xaero_wm_clientworldclass,pl:mixin:APP

...[省略]...

at cpw.mods.modlauncher.Launcher.main(Launcher.java:66) [modlauncher-8.1.3.jar:?] {re:classloading}

-- System Details --

Details:

Minecraft Version: 1.16.5

Minecraft Version ID: 1.16.5

...[省略]...

kotlinforforge@1.17.0

Mod List:?

...[省略]...

...[省略]...

Crash Report UUID: 51bf9b44-64df-46ea-a46e-ef4f0925b633

RoadRunner != Lithium: This instance was launched using RoadRunner, which is an *unofficial* Lithium fork! Please **do not** report bugs to them!

...[省略]...

Mipmaps: 4

Anisotropic Filtering: 1

Antialiasing: 0

Multitexture: false

Shaders: B-籽岷同款光影.zip

OpenGlVersion: 4.6.0 NVIDIA 516.94

OpenGlRenderer: NVIDIA GeForce RTX 3080/PCIe/SSE2

OpenGlVendor: NVIDIA Corporation

CpuCount: 16

[原文件無配色，為方便理解調(diào)節(jié)了字體顏色]

[為減少篇幅刪減了部分內(nèi)容]

較低版本的日志，還會(huì)帶我上一篇文章提到的表格，可是到了高版本，它沒有特別提示哪個(gè)模組出問題啦（或者很難看出）！很令人生氣對(duì)吧w。不過也不要以為線索就只存在于那個(gè)表格哦，出錯(cuò)的模組還以新的面貌出現(xiàn)在另一個(gè)地方......

以這篇崩潰日志為例，我們?nèi)绾慰焖僬业匠鲥e(cuò)的模組？

我們可以看到Description（描述）說明Rendering entity in world（渲染世界中的實(shí)體），導(dǎo)致原因是java.lang.IndexOutOfBoundsException（索引越界），什么鬼？！不懂啊！這兩個(gè)部分并沒有相關(guān)模組彈出來告訴你。不過這么長(zhǎng)的報(bào)告，肯定不止報(bào)告了這個(gè)讓人云里霧里的崩潰原因，對(duì)吧？

嗯，來讓我們看看Description下方的語句，在這一部分中我們可以看到由以下格式組成的語句

at（代碼在以下位置出錯(cuò)） XXX.XXX.XXX.XXX..... (XXX.java:XXX) {XXX:XXX} [XXX:XXX]

在哪里出錯(cuò)？那我知道錯(cuò)誤出在哪里不就能判斷是誰參與了這次崩潰了嗎？

√，本篇總結(jié)，就圍繞一個(gè)主題：從其它地方找到錯(cuò)誤出在哪，然后再去處理它~

你還會(huì)在本篇文章得知，一個(gè)崩潰的引起原因和解決崩潰的方法不止一種你還能刪掉MC來不讓它崩潰對(duì)吧(。

二、尋找位置

位置一（簡(jiǎn)單難度）

讓我們先快速鎖敵，我們可以在語句后面的[XXX:XXX]找到冒號(hào)前面的XXX，這是出現(xiàn)問題的文件。

（你有可能找不到[]，如果你的崩潰日志確實(shí)沒有[]，你也應(yīng)該接著看起碼看看這部分后面我提到的Modid和模組列表的東西，在下面會(huì)提到w）

在這篇報(bào)告中，除了問號(hào)（意為未知文件）外，我們可以找到

lootbeams、eventbus、modlauncher

這三樣?xùn)|西，如果你記得你加過什么模組的話，你就會(huì)知道有一個(gè)名稱跟你添加過的模組名稱很相似，Loot Beams，戰(zhàn)利品光束模組，它參與了這次崩潰。

那另外兩個(gè)是什么呢，是游戲本體或運(yùn)作方式的東西，它們確確實(shí)實(shí)參與了這次崩潰的代碼運(yùn)行，但更多的是，并不會(huì)是游戲本體主動(dòng)讓你游戲崩潰的，而是在它們按部就班地處理著它們的事情的時(shí)候，模組嘗試讓它們幫忙，惹別人生氣自己失誤了，讓正常運(yùn)行的代碼受到連累，被崩潰日志認(rèn)為是兇手的一個(gè)起碼是幫兇對(duì)吧，一起作為呈堂證供啦！

總之，Loot Beams作為一個(gè)主打渲染物品掉落的光束效果的模組，嫌疑已經(jīng)大到可以確認(rèn)是它的鍋了。這時(shí)，一條解決崩潰的思路出現(xiàn)了：我們可以選擇將它刪掉，或者檢查是否有新版本修復(fù)了，或者詢問作者~

但有的時(shí)候你也可能不知道你加了什么模組，也壓根不知道游戲本體會(huì)有什么東西，你可能需要將它們都挑出來唔w

提一句，模組如果在這個(gè)位置一或者下面提到的位置二被記錄下來，一般會(huì)以Modid的形式出現(xiàn)。

挑出來之后你可以到整篇崩潰報(bào)告最下面的位置，找到排列好的模組列表，這模組列表一般都會(huì)帶上所有模組的Modid（而不會(huì)帶上游戲本體或運(yùn)作方式的東西有你也大多對(duì)不上），再找到這個(gè)模組。然后對(duì)應(yīng)到模組，去你的模組文件夾里找有沒有這個(gè)模組~

這種模組列表在不同版本、不同運(yùn)作方式都不相同，但Modid都會(huì)在模組列表里。這里列舉幾種形式。

位置二（普通難度）

看到at后面我還標(biāo)注了三個(gè)顏色的，用點(diǎn)號(hào) “. ” 分開的地方了嗎，就是接下來我要講的部分啦

在這個(gè)位置，我們找到了更多的東西... ...讓我們來看看~

internal、util、lootbeams、minecraftforge、lang、optifine、minecraft

我們除了之前找到的lootbeams，還看到forge、minecraft......你就說它們算不算這次崩潰的參與者嘛。是吧w 但你也清楚問題很少可能出現(xiàn)在它們身上(。再者你總也不能把它們刪了去吧((((((

在這里，我們還能找到internal(內(nèi)部)、util(工具)、lang(語言)，可以想一想，這三個(gè)應(yīng)該是游戲內(nèi)的東西，怎么也不會(huì)是問題的根源。

我們還可以知道Optifine，Optifine確實(shí)跟渲染有關(guān)，所以也有可能是它的問題，有沒有可能會(huì)是Optifine在處理Loot Beams模組的光束時(shí)出了沖突？

注意下喵！at后面的一般是崩潰中執(zhí)行出錯(cuò)代碼的所屬部分

這一長(zhǎng)串部分相當(dāng)于我們計(jì)算機(jī)系統(tǒng)的文件路徑，點(diǎn)號(hào)相當(dāng)于斜杠/

因此像每個(gè)人并非按照統(tǒng)一的標(biāo)準(zhǔn)放自己的文件夾一樣，Modid所在的位置也不一定在第二個(gè)

標(biāo)注出來的三種顏色的位置中都可能是寫下Modid的位置

其中第二個(gè)和第三個(gè)位置最有可能

例如me.pepperbell.continuity

只要你仔細(xì)看，有的時(shí)候作者名字會(huì)放在第二個(gè)位置，而continuity這個(gè)Modid被放到了第三個(gè)位置......

回到正題喵，在這個(gè)位置，我們找到了比位置一更多的一個(gè)崩潰原因可能，這居然給了我們的解決崩潰問題的嘗試多了一條更好的！我們可以嘗試先暫時(shí)禁用Optifine，讓它先不要渲染物品光束進(jìn)入一次存檔查看是否能規(guī)避了這個(gè)問題。這不比直接刪掉我心愛的模組好多啦？

位置三：（高級(jí)難度）

Description的意思，應(yīng)該是在渲染世界上的某個(gè)實(shí)體除了問題...那我找到這個(gè)實(shí)體把它刪掉不就好了？

沒錯(cuò)啦~你甚至可以在--?Entity being rendered（被渲染的實(shí)體）?--找到被渲染出錯(cuò)的實(shí)體——

Entity Name（實(shí)體名稱：）: item.tetra.modular_double

如果把這個(gè)實(shí)體刪掉，那不也一樣能不讓這個(gè)崩潰發(fā)生了！新的思路！嗚呼！

這個(gè)思路只會(huì)出現(xiàn)在少部分崩潰，并不適用所有，一般看情況而定，你也應(yīng)該看看A detailed walkthrough of the error, its code path and all known details is as follows:下面有沒有特別的東西，再結(jié)合描述里提到的思考哦~

至于如何處理這類特別的實(shí)體出錯(cuò)崩潰，到時(shí)我會(huì)有一篇特別的疑難雜癥發(fā)出來，已經(jīng)搓好一部分稿子了，到時(shí)候見~

三、解決方案

在以上的例子，解決方案有三種思路呢，好耶！

事實(shí)上，這個(gè)崩潰是通過第一個(gè)方案修復(fù)的，第二個(gè)方案是推理出來的一個(gè)結(jié)果，能不能實(shí)現(xiàn)還需要實(shí)機(jī)考證，第三個(gè)方案需要其它工具，復(fù)雜程度肯定比前兩種高只是相比，它本身操作起來對(duì)我來講不是特別困難w。

如果我們只需不要崩潰，又可以不需要這個(gè)Loot Beams模組，直接刪掉，那是最快的。

但如果你想保留自己心愛的模組，第二種第三種方案都值得去做，不是喵嗚？

所以內(nèi)，在選擇解決方案之前，需要看的全面，并結(jié)合自己的需求，同時(shí)還可能需要嘗試不同方案能不能實(shí)現(xiàn)，這樣就能解決崩潰啦喵~

話外

好耶終于寫完了(

現(xiàn)在已經(jīng)重新接受我的世界崩潰解決請(qǐng)求啦~

如果你看到了這里，你已經(jīng)能找到大部分高版本的游戲崩潰幕后黑手啦，并且能嘗試分析得到更多的崩潰解決思路啦！

如果你仍然看不懂，你還可以到評(píng)論區(qū)下方留言，我還能努力嘗試修改一下表述喵！

記得...點(diǎn)贊哦~投幣你看著就好，不投也沒關(guān)系喵w~

標(biāo)簽：MC 我的世界日志 Minecraft 崩潰報(bào)告我的世界崩潰崩潰日志