Copy JVM crash report to description

[Marcono1234]

The Problem

Relates to #281 and #685, depends on #627 (so we first agree on the expected behavior)

Similar to #281, it would be useful if Arisa could include a snippet of JVM crash reports to make finding existing reports easier.
We have recently been told by the Mojang developers that we should avoid resolving JVM crashes as Invalid (unless we are certain that they are caused by incompatible software of outdated drivers). However, the issue is that such crashes cannot be easily reproduced (or depend on the OS and device). It is therefore even more important for these reports to find existing ones to allow the reports to get Community Consensus as Confirmation Status and to get a broader picture of which devices are affected.
Additionally it feels like JVM crashes have become more frequent recently (maybe due to rendering changes?).

Possible Solution

Extend mc-crash-lib to support extracting JVM crash report snippets.
We can probably extract everything starting at ... --- T H R E A D --- ... up to (excluding) Register to memory mapping::

---------------  T H R E A D  ---------------

Current thread (0x0000016017521020):  JavaThread "Render thread" [_thread_in_native, id=6632, stack(0x0000002668200000,0x0000002668300000)]

Stack: [0x0000002668200000,0x0000002668300000],  sp=0x00000026682fd920,  free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [atio6axx.dll+0xbbb1f1]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J 8093  org.lwjgl.opengl.GL15C.nglBufferData(IJJI)V (0 bytes) @ 0x000001602321daee [0x000001602321daa0+0x000000000000004e]
J 29116 c2 dqg.a(Ljava/nio/ByteBuffer;Ldqp$b;Ldqp;ILdqp$a;IZ)V (468 bytes) @ 0x000001602445626c [0x0000016024455d00+0x000000000000056c]
J 29113 c2 enh$a.a(Lenp;)V (65 bytes) @ 0x0000016024201848 [0x0000016024200f00+0x0000000000000948]
J 19569 c2 enh$a.getBuffer(Lenp;)Ldqo; (96 bytes) @ 0x0000016023643988 [0x00000160236436a0+0x00000000000002e8]
J 27251 c2 ewm.a(Ldqk;Lenh;ILatf;FFFFFF)V (25 bytes) @ 0x0000016023e61c30 [0x0000016023e60d00+0x0000000000000f30]
J 27160 c2 esx.a(Latt;FFLdqk;Lenh;I)V (616 bytes) @ 0x00000160242536a0 [0x00000160242522c0+0x00000000000013e0]
J 23986 c2 etc.a(Latv;FFLdqk;Lenh;I)V (38 bytes) @ 0x0000016023a3c52c [0x0000016023a3c4e0+0x000000000000004c]
J 24049 c2 etc.a(Latf;FFLdqk;Lenh;I)V (17 bytes) @ 0x0000016023c1f1fc [0x0000016023c1f1a0+0x000000000000005c]
J 25490 c2 erv.a(Latf;DDDFFLdqk;Lenh;I)V (367 bytes) @ 0x0000016023fa4e34 [0x0000016023fa4640+0x00000000000007f4]
J 26544 c2 enf.a(Latf;DDDFLdqk;Lenh;)V (104 bytes) @ 0x0000016024147e4c [0x0000016024147900+0x000000000000054c]
J 27181 c2 enf.a(Ldqk;FJZLduz;Lena;Leng;Ld;)V (2774 bytes) @ 0x0000016024285684 [0x0000016024282d80+0x0000000000002904]
J 25751 c1 ena.a(FJLdqk;)V (587 bytes) @ 0x000001601d3ed1cc [0x000001601d3ea760+0x0000000000002a6c]
J 10015 c1 ena.a(FJZ)V (912 bytes) @ 0x000001601c56ab34 [0x000001601c569ac0+0x0000000000001074]
J 24402 c2 dvo.f(Z)V (968 bytes) @ 0x0000016023dec918 [0x0000016023deabe0+0x0000000000001d38]
j  dvo.e()V+81
j  net.minecraft.client.main.Main.main([Ljava/lang/String;)V+1328
v  ~StubRoutines::call_stub

siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000000

(full crash report (private))

When Register to memory mapping: is not present, which appears to be the case for native frames sometimes the snippet should probably go up to (excluding), ... --- P R O C E S S --- ... (full crash report (private)). Though in that case the cause does not seem to be mentioned in that part, so we have to include the indented lines in the header after A fatal error has been detected by the Java Runtime Environment (maybe we could simply always include them, even if they would be doubled for crashes with Java frames then).
If none of these section markers are found we should probably not try to include the content in the description.

We could also ask the Mojang devs whether there is something else to check when determining whether two JVM crashes are the same.

We could possibly also add the ability to deobfuscate Java class names, but that might be out of scope for this task since it requires custom logic for detecting Minecraft versions in the JVM crash reports and also custom regex patterns for matching class and method names.

[violine1101]

IMO it would be enough if Arisa would simply edit the hs_err_pid file to remove the sensitive parts, and then upload that file and delete the unredacted one, similar to how I've done it in https://bugs.mojang.com/browse/MC-229049 manually.

Edit: Actually these are two separate things, mine is about getting rid of the privacy issue, yours is about finding these crashes easier. I think I'll create a new issue for mine, it should be unrelated to this one.

Edit 2: Created #704

[violine1101]

We could possibly also add the ability to deobfuscate Java class names, but that might be out of scope for this task since it requires custom logic for detecting Minecraft versions in the JVM crash reports and also custom regex patterns for matching class and method names.

Getting the version for deobfuscation would be pretty easy from what I can tell, the line starting with java_command has --version <versionNumber> in it.

[violine1101]

Interestingly, JIRA's search appears to be very weird when searching for JVM crashes. I can't find MC-229049 by searching for lwjgl_stb32.dll or lwjgl stb32. Only lwjgl stb actually finds that bug report.

[Marcono1234]

Interestingly, JIRA's search appears to be very weird when searching for JVM crashes. I can't find MC-229049 by searching for lwjgl_stb32.dll or lwjgl stb32. Only lwjgl stb actually finds that bug report.

Maybe it had not been indexed yet? I am able to find it with text ~ "lwjgl_stb32.dll".

[violine1101]

Ah yeah, that's probably what it was. I can find it now too. Strange that it took that long to index.