5.4.0b20 Unable to WebGL build w/ Crash Reporting

[GarthSmith]

Hello! I apologize if this was already reported on the forums.

I have created a new Unity 5.4.0b20 project, enabled Unity Performance Reporting, then imported the Unity package at https://public-cdn.cloud.unity3d.com/UnityCrashLog.unitypackage . I edited the example to use my own Unity Project ID.

I cannot perform a WebGL build. I receive this error when building.

Fatal error in Mono CIL Linker
System.Exception: Error processing method: ‘System.Boolean UnityEngine.CrashLog.Util.Rest/d__4::MoveNext()’ in assembly: ‘UnityEngine.CrashLog.dll’ —> Mono.Cecil.ResolutionException: Failed to resolve System.Void UnityEngine.Ping::.ctor(System.String)
at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference reference)
at Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction)
at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body)
at Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
at Mono.Linker.Steps.MarkStep.ProcessQueue()
— End of inner exception stack trace —
at Mono.Linker.Steps.MarkStep.ProcessQueue()
at Mono.Linker.Steps.MarkStep.Process()
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.RunDriver(Driver driver)

I will be submitting a bug and will update with the case # when I receive it.

[GarthSmith]

This has been reported as Case # 803731.

Also, here’s a screenshot of the error in the Unity Editor console.

[ChrisLundquist]

Hey Garth!

So I have a blog post in the works to help answer this, but you’ve hit this before it has been published!
So, the good news is that you don’t need the plugin any more.

For 5.4 I was able to integrate performance reporting into the editor.
You should be good to go just by clicking “Enable” in the services tab.

Likewise, you’ll probably want to remove the plugin and any code referencing it (like the initialization code), as we can find your project id since we’re in the editor.

The bad news is that while the editor integration does “work” it isn’t entirely too helpful.
As you probably know, we use LLVM to transpile C# into javascript, so the stack trace reported won’t be anywhere in your code as it was generated javascript.

Hope this helps,
Chris Lundquist

[system]

@ChrisLundquist

The bad news is that while the editor integration does “work” it isn’t entirely too helpful.
As you probably know, we use LLVM to transpile C# into javascript, so the stack trace reported won’t be anywhere in your code as it was generated javascript.
Chris Lundquist

This is good to hear, I am going to have to make these changes now as well.

Is there a way we can go between, and figure out what caused the crash, we have a couple of nasty lock ups that produce nonsense errors that we would like to sort out.

Is there any way currently to take those stack traces and make sense of were a crash is coming from?

[GarthSmith]

Thank you @ChrisLundquist ! Sounds good that we don’t need the plugin anymore. I hadn’t thought about the stacktrace not being useful, this is my first time implementing on WebGL. (Still would be nice to know if/when crashes are occurring!) I’ll look forward to that blog post. =)

@ I am just getting into WebGL builds, so I have no idea what our C# code ends up looking like in Javascript/WebGL. I think the process is C# → CIL → put through LLVM → get Javascript. I assume function names get stripped out and there would have to be some kind of symbols lookup (similar to a .pdb file) that might be able to point towards some kind of function, though my experience with these kind of toolchains is that a compiler may have changed code due to optimizations. (Ie. there’s no nice “This Javascript error corresponds to line 827 of your C# script.”) I found some LLVM debugging documentation here, but I haven’t worked with WebGL enough to get experience debugging it.

[ChrisLundquist]

Is there any way currently to take those stack traces and make sense of were a crash is coming from?

There is, but we don’t have a feasible way to do it yet.

As Garth Smith said:

@Garth Smith

I think the process is C# → CIL → put through LLVM → get Javascript. I assume function names get stripped out and there would have to be some kind of symbols lookup (similar to a .pdb file) that might be able to point towards some kind of function, though my experience with these kind of toolchains is that a compiler may have changed code due to optimizations.

This means we would need the symbols file your laptop / build machine generated when transpiling the C# into Javascript. Then we would take your javascript stack trace and reverse it through your symbols. At the moment we don’t have the means to do this.

I suppose it is technically possible for you to do this if you downloaded your exceptions from the API, but it would be gritty to say the least.

It turns out this probably isn’t too different from native crashes (get symbols, decode symbols), so we’ve decided to focus our efforts there for now. I think once we have native crashes for mobile / desktop, doing similar for WebGL would be “easy”.

Hope this helps,
Chris Lundquist