TextMesh Pro exe crash after Cloud Build with TMP 1.4.1 (Unity 2018.4 LTS)

After an update to TextMeshPro 1.4.1 on Unity 2018.4 LTS the exe file that UCB creates is corrupt and will just crash the game even before the stock Unity splash screen.
I noticed this on my own project so I created a fresh project to narrow down what could be causing it, this is when I discovered it is TMP so I used that project to file the bug report.

Local builds are working fine, but for some reason the UCB is borked.

Crash report is blaming

Bug report 1168142

Here is link for exe for proof of crash https://developer.cloud.unity3d.com/share/share.html?shareId=ZkX2k2c0aE

_________________________________________

I have just tried the same process with Unity 2019 and TMP 2.0.1 (2019 verified) and the exe still crashes. I am so confused.

__________________________________________

I have made a post in UCB thread but I also think it should be mentioned here.

Post from UCB
https://forum.unity.com/threads/exe-crash-after-ucb-with-tmp-1-4-1-unity-2018-4-lts.707249/

 

It is possible the issue is related to Unity incorrectly referencing the Editor Assemblies in the builds. This is a bug that has been reported and fixed but not yet backported.

This issue can occur with local builds as well. The crash is immediate upon start.

The workaround to avoid this issue when building locally is to switch the Architecture to x86 (wait for unity to do its thing) then switch back to x86_64 and then build. Changing Architecture mode forces Unity to re-sync the assemblies which resolves the issue which is related to stale assembly references.

Not sure if it is possible to do this trick on UCB.

The cause of the crash is the TMP_FontAsset having (1) single EDITOR only serialized property which the Editor assembly references but not the runtime assembly. So if the wrong assembly is used, it goes boom!

This serialized property is used to keep a persistent reference to the font file the font asset is using.

P.S. I did add this information to your bug report (internally).

 

Just wondering what you mean by "its fixed but not back ported yet". I just updated project to latest 2019.1 and the issue still remains. So what version of Unity/TMP is this fixed?

Local builds are fine because of the work around that you mentioned so we can still proceed to make builds for testing, but I am wondering how can this work around be implemented in UCB? Thanks.

Also is there anywhere else I can get some help with this? We're paying for two pro licenses right now for features we can't even use.

 

Assuming this is the same issue I referenced, I was fixed in one of the 2019.3 alpha. Requests to have this back ported to 2018.4 / 2019.1 and 2019.2 have been made.

Unfortunately, I don't have enough experience with UCB to provide an answer / workaround. The key would be to find a way to force re-syncing of the assemblies like changing the Architecture does in local builds.

The key step was to submit the bug report which you have done. I also added my notes to the bug report and now await feedback from the relevant QA / Dev folks overseeing UCB and build system.

 

OK, downgrade to TMP 1.3.0 make cloud build binary run again.

But are you sure it's because of "serializefield" under UNITY_EDITOR?

I ask this because, I have a script on my own side, which also include specific serialize field under define symbols (One is my custom one and another is also UNITY_EDITOR), it didn't make the app crash. But on my side that script is not a scriptable object, but a monobehaviour, which is attached only on a game object prefab, which in my case won't be initialized on this runtime platform.

 

The easiest way to test this is by editing the TMP_FontAsset.cs file in version 1.4.1 to remove the #if UNITY_EDITOR around this field and testing again if UCB will still crash.

Code (csharp):

1.  
2. #if UNITY_EDITOR
3. /// <summary>
4. /// Persistent reference to the source font file maintained in the editor.
5. /// </summary>
6. [SerializeField]
7. internal Font m_SourceFontFile_EditorRef;
8. #endif
9.  

 

But those files are read only and can't be edited. Unless I copy all the files out, remove the package, and put them back in my project.

I may do this another time. Or can someone else test it?

 

The package lives in the Global package cache (which on Windows is located at "...\AppData\Local\Unity Cache\cache") and you are correct that these files are read-only but you can change that particular file to not being read-only and make the change.

The impact of this change would mean that Static font asset which do not need a reference to their source font file would include the source font file regardless in the build but that should avoid the crash.

I know the above solution works but since I am not 100% certain that is the source of the crash you are experiencing, that is why I was asking for you to test it which would also allow you to get around the issue until this gets fixes / back ported to the version of Unity you are using.

 

Hey I can edit the file but its not showing up in my git diff so not sure how I can push the changes?

 

The change won't show up since it is done in the package which is not part of the local project and as such no tracked by your source control.

We can get around this by embedding the package but that is not something that we need to worry about for testing this issue / crash. If the change gets around the crash then we can look at making sure the change is persistent until the fix for this issue is back ported.

 

Yes this seems to have fixed the crashing issue locally. I deleted the Library folder to make sure the cache was fresh before doing a build and i didn't need to switch environments - just straight away did a windows64 build and it.

This is promising. How can I now embed this to test it in a cloud build?

 

If you modified the TMP_FontAsset.cs script in the Global cache location then the change should be persistent until you upgrade the TMP package.

Embedding of the package in the local project should not be necessary but in case you want to do this, you simply copy the "com.unity.textmeshpro@1.4.1" folder located in the global cache / packages / packages.unity.com to the Packages folder in your local project. When a package is embedded, you won't be able to get the newer version of the TMP package until you remove the embedded package.

Again, this temporary removal of the #If UNITY_EDITOR conditional will only be necessary until the build system fix is back ported to your version of Unity.

 

It worked! Thank you very much, cloud builds successfully and with no crash When the backport comes ill make sure to remember to delete the copy in my Packages folder.

 

remove unity 2018.4 from verified for tmpro 1.4.1 if it doesn't work please

 

Can you please be more specific as to what issue you are having?

 

well, my ios/android TeamCity build gets stuck on compiling shaders on 2018.4.12... Then I tried your solution with removing #define and my Editor->Play led to crash.
I can't check 2018.4.19 right now, our project is not building on it for other reasons... Anyway it is a bit strange that this "2018.4 verified" doesn't contain minor version

 

We're using 2018.4.13 and it works, I think it was fixed on unity's side at around 2018.4.7.

TMPro 1.4.1 has not changed, but it works on my side for both cloud build and local build.

About stuck on compiling shader, I think it's not due to TMP, you can try close Unity and restart computer. Sounds ridiculous but it had helped me a few times.

I think you shouldn't try that fix now because it's not necessary and may lead to other unknown behaviour.

 

try switching it to x86 ... and try to build..
it may show warnings and errors.. try to fix that, build in x86.
then switch it back to x64.. and it built..
this help me

 

Yeah you shouldn't need to do that work around now. I've had no problems in Unity 2019.x.x

 

The above was to get around a bug in the build system where it was not correctly refreshing / rebuilding the resources. In some case, it was using the Editor serialized data in the build which made for some unhappy results.