BurstDebugInformation_DoNotShip in builds

After a fairly recent update to Burst, I'm not seeing a folder named this in my builds:

Gravia_BurstDebugInformation_DoNotShip

A couple of questions:

1) Why is this being generated? I'm creating a Release build of my game, not a dev build. Is there a setting that is causing this to be generated?

2) Can I prevent this from being generated? It seems like I have "Force Debug Information" unchecked, but this is still being created:



3) What is the consequence of deploying this with a build, in the event that I somehow overlook deleting it from the build? It ultimately contains a single file named "lib_burst_generated"

Thanks.

 

in my experience, 1.6.0 introduced this file for pretty much all builds. We had to adjust all our CI jobs to ignore that folder, felt a bit messy - but doable

 

Thanks. I'm on 1.6.0, same as @Carpet_Head. I didn't see this when doing builds on earlier versions of Burst.

And yes, if I drill down in that directory, all I ultimately find is "lib_burst_generated.txt". I assumed it was not necessary to run the game (since otherwise why would it tell me not to ship that content), but I wanted to know whether there was any consequence if I were to ship it, by mistake.

 

Hi,
Is there a clean way to prevent Unity from generating this folder ?

 

You could try setting up a post build script and delete it each time

 

This is what I'm doing at the moment, I guess it works but I was hoping there might be an hidden setting somewhere to just skip its creation altogether.

 

@sheredom Is there a way to turn it off altogether? It clutters the hard drive and complicates some automation tasks.

 

I am also wondering if there is a way to stop it from being created? @sheredom I will request this on the roadmap

 

Thanks, no harm in it being on by default to generate such files, but most useful to us developers is an option to disable it if we choose to for various reasons of not wanting extra folders in the build folder close to release etc

 

By any chance, is it possible to share this code?

 

This is how I do it:

At the end of my build function I call the following DeleteBurstDebugInformationFolder function with the build report returned by the BuildPipeline.BuildPlayer function (only if the build succeeded).

Code (CSharp):

1. static void DeleteBurstDebugInformationFolder([NotNull] BuildReport buildReport)
2. {
3.     string outputPath = buildReport.summary.outputPath;
4.  
5.     try
6.     {
7.         string applicationName = Path.GetFileNameWithoutExtension(outputPath);
8.         string outputFolder = Path.GetDirectoryName(outputPath);
9.         Assert.IsNotNull(outputFolder);
10.  
11.         outputFolder = Path.GetFullPath(outputFolder);
12.  
13.         string burstDebugInformationDirectoryPath = Path.Combine(outputFolder, $"{applicationName}_BurstDebugInformation_DoNotShip");
14.  
15.         if (Directory.Exists(burstDebugInformationDirectoryPath))
16.         {
17.             Debug.Log($" > Deleting Burst debug information folder at path '{burstDebugInformationDirectoryPath}'...");
18.  
19.             Directory.Delete(burstDebugInformationDirectoryPath, true);
20.         }
21.     }
22.     catch (Exception e)
23.     {
24.         Debug.LogWarning($"An unexpected exception occurred while performing build cleanup: {e}");
25.     }
26. }

 

I made a helper script for this which does the following once a build has ran:

1. If building for IOS, removes the Xcode build target platform 'My Mac' which would otherwise try to automatically run your IOS app on your Mac when using Build & Run from Unity on Xcode build target
2. If using the Burst package, the Burst Debug folder will be deleted on a successful build
3. If building for il2cpp, the il2cpp Debug folder will be deleted on a successful build

Code (CSharp):

1. using System;
2. using System.IO;
3. using UnityEditor;
4. using UnityEditor.Callbacks;
5. #if UNITY_IOS
6. using UnityEditor.iOS.Xcode;
7. #endif
8. using UnityEngine;
9. using UnityEngine.Assertions;
10.  
11. public class CleanupPostProcessorBuild
12. {
13.  
14.     [PostProcessBuild(2000)]
15.     public static void OnPostProcessBuild(BuildTarget target, string path)
16.     {
17. #if UNITY_IOS
18.         Debug.Log("iOSBuildPostProcess is now postprocessing iOS Project");
19.  
20.         var projectPath = PBXProject.GetPBXProjectPath(path);
21.  
22.         var project = new PBXProject();
23.         project.ReadFromFile(projectPath);
24.  
25.         var targetGuid = project.GetUnityMainTargetGuid();
26.  
27.         project.SetBuildProperty(targetGuid, "SUPPORTS_MAC_DESIGNED_FOR_IPHONE_IPAD", "NO");
28.  
29.         try
30.         {
31.             var projectInString = File.ReadAllText(projectPath);
32.             projectInString = projectInString.Replace("SUPPORTS_MAC_DESIGNED_FOR_IPHONE_IPAD = YES;",
33.                 $"SUPPORTS_MAC_DESIGNED_FOR_IPHONE_IPAD = NO;");
34.             File.WriteAllText(projectPath, projectInString);
35.         }
36.         catch (Exception e)
37.         {
38.             Debug.LogException(e);
39.         }
40.  
41.         project.WriteToFile(projectPath);
42. #endif
43.         string outputPath = path;
44.  
45.         try
46.         {
47.             string applicationName = Path.GetFileNameWithoutExtension(outputPath);
48.             string outputFolder = Path.GetDirectoryName(outputPath);
49.             Assert.IsNotNull(outputFolder);
50.  
51.             outputFolder = Path.GetFullPath(outputFolder);
52.  
53.             //Delete Burst Debug Folder
54.             string burstDebugInformationDirectoryPath = Path.Combine(outputFolder, $"{applicationName}_BurstDebugInformation_DoNotShip");
55.  
56.             if (Directory.Exists(burstDebugInformationDirectoryPath))
57.             {
58.                 Debug.Log($" > Deleting Burst debug information folder at path '{burstDebugInformationDirectoryPath}'...");
59.  
60.                 Directory.Delete(burstDebugInformationDirectoryPath, true);
61.             }
62.  
63.             //Delete il2cpp Debug Folder
64.             string il2cppDebugInformationDirectoryPath = Path.Combine(outputFolder, $"{applicationName}_BackUpThisFolder_ButDontShipItWithYourGame");
65.  
66.             if (Directory.Exists(il2cppDebugInformationDirectoryPath))
67.             {
68.                 Debug.Log($" > Deleting Burst debug information folder at path '{il2cppDebugInformationDirectoryPath}'...");
69.  
70.                 Directory.Delete(il2cppDebugInformationDirectoryPath, true);
71.             }
72.         }
73.         catch (Exception e)
74.         {
75.             Debug.LogWarning($"An unexpected exception occurred while performing build cleanup: {e}");
76.         }
77.     }
78.  
79. }

 

It would be nice if there was an option to disable it's generation, esp if people are having to write code to delete them afterwards. Otherwise it's somewhat error prone and takes up a lot of space if you're using CI, our il2cpp debug output is 1.2GB

 

@sheredom can you help illuminate how we would use this file to help debug built games? I would prefer to delete the file, seeing no obvious use for it, but maybe there's something I'm missing? I couldn't find anything about this in a couple google searches either

 

This is more a guess in the blue, but I'd assume this is what allows you to see the error-cause sourcecode with a regular process debugger (visual studio -> debug -> attach to process -> select your running game) when an error occurs.

 

The folder gets generated even if it is empty, without any files in it other than empty folders. Can we get an option to disable it, or at least have Unity not generate it if it doesn't contain any files?

 

Burst is compiled to native machine code, which is made of raw binary CPU instructions. When such code crashes in the wild (for example, on people's Android devices) it generates a crash dump with native stack traces which are just a bunch of memory address offsets into the native binary since native code doesn't contains things like function names.

That folder contains debug symbol files generated during build contains a map of the source code to the final machine binary code, and is used to make a crash dump stack trace human-readable. Without it you'll have little hope of debugging crashes that happen on users' devices. That's usually when people learn the hard way they actually need to keep those files somewhere.

Also, you cannot generate those after the fact: the symbol information is only valid for the executables generated alongside it. If you build again even without any changes both the binary and the symbols will be different.

 

ah cool, thanks for the explanation @Neto_Kokku, that makes perfect sense. I'm accustomed to saving the symbols for builds already, good to know this is another artifact to hang on to

 

How can I use the pdb or dSYM files to convert addresses from a stacktrace to a line number?
I couldn't find information on it online...

 

Yeah, honestly, why do we need to make a post-build script to clean up a folder that we don't want to ship?

 

Why not use the designated log folders to store this information. Why on earth choose to clutter the build folder for everyone? Unbelievable.

 

The BurstDebugInformation_DoNotShip folder.

 

Oh I was thinking the player log folder. On windows:
%USERPROFILE%\AppData\LocalLow\CompanyName\ProductName\

 

When you do make that change, please also make an option to disable it so that we don't have to make our own hacky build processor scripts.

 

i get this folder alone when building apk but no apk. please can someone help solve this

 

Wouldn't it make sense to only make this folder for debug builds, then?

 

Exactly this. Accidentally zipping a quick build for testers in release mode, and ending up with all that debug data shipped is a regular occurrence since it's easy to forget there's that damn debug folder inside. I took a look through the files and it lists things I think I'd rather people not know are part of the builds, so it'd be nice to be able to simply disable the generation of that data completely. Nobody has to know what namespaces, packages or dll's I'm using. I'd wager most people delete that to begin with or simply send their games up to the cloud with it, blisfully unaware.