Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice
  3. Join us on November 16th, 2023, between 1 pm and 9 pm CET for Ask the Experts Online on Discord and on Unity Discussions.
    Dismiss Notice

5.4.0b20 Unable to WebGL build w/ Crash Reporting

Discussion in '5.4 Beta' started by GarthSmith, Jun 7, 2016.

  1. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    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.

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

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    This has been reported as Case # 803731.

    Also, here's a screenshot of the error in the Unity Editor console.
    upload_2016-6-7_14-32-58.png
     
    Last edited: Jun 7, 2016
  3. ChrisLundquist

    ChrisLundquist

    Unity Technologies

    Joined:
    Mar 2, 2015
    Posts:
    55
    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
     
    GarthSmith likes this.
  4. Baraphor1

    Baraphor1

    Guest

    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?
     
  5. GarthSmith

    GarthSmith

    Joined:
    Apr 26, 2012
    Posts:
    1,240
    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. =)

    @chriscisco 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.
     
  6. ChrisLundquist

    ChrisLundquist

    Unity Technologies

    Joined:
    Mar 2, 2015
    Posts:
    55
    There is, but we don't have a feasible way to do it yet.

    As Garth Smith said:

    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