Search Unity

Resolved How to get line numbers in production build

Discussion in 'Windows' started by UnLogick, Mar 3, 2021.

  1. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    I need to get line numbers into our release builds. This will allow us to use proper error handling services.

    Right now the official solution from unity is to turn on development build.

    Unfortunately this turns on the development build notice in the corner as well as the development console, which according to unity you can only remove by turning off development build.

    Why is this a thing? You even have the "UnityEditor.WindowsStandalone.UserBuildSettings.copyPDBFiles = true;" flag why don't you respect it?

    I don't particularly care about compiler optimizations, we're running windows standalone builds that are not pushing the hardware. I care more about bug fixing and improving stability than I care about performance.

    Currently using 2019.4.18f1 LTS.
     
    kerjemanov and davidrochin like this.
  2. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    Since the thread went completely unnoticed I dived in deeper in an attempt to bypass it. I've thrown pretty much every tool in the box at it and been completely denied.

    I've tried replacing the shaders with non-rendering shaders
    "Hidden/Internal-GUITexture"
    "Hidden/Internal-GUITextureClip"
    "Hidden/Internal-GUITextureClipText"
    This seriously F***s up the Unity Editor, but the standalone build completely ignores it.

    I've tried overriding GUIStyle.onDraw
    Using my good old friend ILSpy I dived deep into the innards of Unity to notice that all GUI.Label invocations is funnelled through GUIStyle.onDraw. You need a certain amount of reflection code to first create a suitable delegate (one of the parameters is an internal struct, thanks!) but once I overcame that hurdle I managed to get it working and F*** up everything inside of Unity. Unfortunately the runtime doesn't share the same code path so again this was denied. Tossing ILSpy at the actual runtime reveal no route to shortcut this process.

    I tried getting rid of the watermark_dev texture
    The logic here is that there is a forum thread stating that you can close the development console as soon as it opens, since my error handling service is already subscribed to the log watcher all I'd need is to get rid of the watermark. However again this is an internal resource that my frame debugger can tell me is there, but I have no way of getting my filthy hands on and replace with something a bit more to my liking. (Completely transparent).

    I tried making a development build and production build and copy the dlls and pdbs
    Such having a production build with the unoptimized dlls with proper pdbs, but Unity locked this down so all attempts to read the stacktrace with line numbers will completely ignore the pdbs! I tried diffing the two builds and toggle each file by hand but the development mode seems to be a single toggle that completely denies any attempt to get line numbers or remove the watermark.

    What the F*** is going on?
    Clearly some effort has been put into denying my line numbers, but why? Who on earth thought making such a hard differentiation between development builds and production builds was important? And why?
     
    kerjemanov and davidrochin like this.
  3. kerjemanov

    kerjemanov

    Joined:
    Aug 16, 2019
    Posts:
    7
    Did you try to use custom build to solve your problem? They even have Scriptable Build Pipeline package for such purposes. I don't know whether it can resolve your problem or not, but I would try to look in this direction if you haven't already done it.
     
  4. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    Good suggestions.

    I already looked at build solution which allows you to tweak many things related to your assemblies but you cant change the unity framework .

    I did look at the scriptable build pipeline but this is for assetbundles only!

    The main problem here is that this is hard coded into the standalone player. Your c# code is loaded as a dll by the player, so it's part of the framework that you cant touch.
     
    deeprest and kerjemanov like this.
  5. deeprest

    deeprest

    Joined:
    Jun 8, 2016
    Posts:
    17
    Last edited: Apr 20, 2021
  6. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,680
    Hey. I created an empty Unity project (in Unity 2020.2.4f1 as that's what I happen to have installed) with one script in it:

    Code (csharp):
    1. using System;
    2. using UnityEngine;
    3.  
    4. public class NewBehaviourScript : MonoBehaviour
    5. {
    6.     void Start()
    7.     {
    8.         Debug.Log(Environment.StackTrace);
    9.     }
    10. }
    Then, I created two windows standalone player builds: one development, one non-development. Once the build completed, I needed "build_nondev\New Unity Project (293)_Data\Managed" and copied over the same folder from development build. When I start the build, there's no development build watermark or the developer console, but the player log contains this:

    Code (csharp):
    1.   at System.Environment.get_StackTrace () [0x00000] in <2b3a3162be434770b7a4fac8b896e90c>:0
    2.   at NewBehaviourScript.Start () [0x00001] in F:\Projects\Unity Projects\New Unity Project (293)\Assets\NewBehaviourScript.cs:8
    Is this not what you see?
     
  7. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    Retested in 2020.3 and you're right, the hack works there. Not sure exactly which version of 2020 addressed this but the hack works.

    I had to go back to an old version to preserve my sanity and it does NOT work in 2019 series! I even went up to 2019.4 when I reported it because it's LTS, we're using 2019.2 but didn't want to report the issue on something that's not LTS.

    On top I tested the variations, you used Environment.StackTrace where error logging typically uses Diagnostics.StackTrace because it can extract stack traces from exceptions. Also tested StackTraceUtility and they all worked in 2020.3 which means the hack is confirmed.