#unity UIから「Save As...」ボタンを外したらUnityエディタがクラッシュするようになった話（TextMeshPro Deep Dive #4）

　年の瀬です。皆様いかがお過ごしでしょうか。２０２４年も大変お世話になりました。来年もよろしくお願いします。

　土屋はこの年末の忙しい最中、「Unityエディタ拡張の自作ツールで「Save As...」ボタンを削除したら特定タイミングでUnityエディタがクラッシュするようになる」という、中々にレアな（Unity内部の）バグを引きまして、原因特定に丸一週間を要しました。

　今回はその原因特定にいたるまでの記録です。状況がレア過ぎて応用が利く機会は恐らく無いですが、読み物としてお楽しみ頂ければと思います。

対応するUnityバージョン

Unity 6(6000.0.25f1)
Unity UI 2.0.0

何をしていたか：TMPro.FontAssetCreatorWindow.csをカスタマイズ実装していた。

　現在、土屋は、UnityでTextMeshPro（以下「ＴＭＰ」）を経由せずに文字列を画面に描画できる、オリジナルのテキスト描画フレームワークを開発しています*1。この作業の過程で、ＴＭＰが提供している「Font Asset Creator」というツールを、自身のフレームワークに移植していました。

（これがFont Asset Creator。ウィンドウのサイズによってテクスチャプレビューの表値位置が下部／右部で切り替わります）

　Font Asset CreatorはUnityエディタ上で動作するツールで、TrueTypeフォントを読み込んでTMP_FontAssetアセットファイル（以下フォントアセット）を出力する機能を持ちます。

　フォントアセットには、フォントの各文字が描画された巨大なテクスチャ（「テクスチャアトラス」と言います）と、各文字のパラメータが格納されています。ゲーム実行時には、文字毎のパラメータを元にテクスチャアトラスから必要な領域を切り出して、画面に文字を描画する訳です。

　制作中のフレームワークではフォントアセットも独自フォーマットを使う予定で、このツールの実装を流用することにしたのでした。

「Font Asset Creator」ツールの構造

　「Font Asset Creator」ツール（以下「元ツール」）は、Unityのエディタ拡張の仕組みを使っていて、実装はTMPro.FontAssetCreatorWindow.csに記述されているFontAssetCreatorWindowクラスになります。

　このクラスでは、内部でTextCore.LowLevel.FontEngineと言うstaticクラスを呼んでいます。FontEngineはTrueTypeフォントファイルから情報を抽出したり、文字をテクスチャに描画する処理を担当しているネイティブコードです。つまり、このFontEngineが、元ツールの処理の中核を担っているわけです。

ツールの改造を開始

　Unity上でオリジナルのフォントアセット生成ツールを実装するには、FontEngineを制御する必要があります。しかし、FontEngineクラスはたいしてドキュメントが用意されておらず、またネイティブコードなので実装がブラックボックスです。

　そこで、元ツールを解析して、FontEngineを呼ぶ処理を流用する事にしました。元ツールは非常に機能が多く、またコードがメンテ性に難があったので、コード全体をリファクタリングしながら、土屋が必要な機能以外はゴリゴリ削っていく事にしました。

起きた事象：特定タイミングでUnityエディタがクラッシュするようになった。

　リファクタリングは順調に進んでいたのですが、ツールをテストしていると、不定期にUnityエディタがクラッシュする事に気づきました。

（↑この２週間ひたすら遭遇したポップアップ）

　クラッシュの発生条件は当初確定しておらず「ツールを起動して１０秒以内に処理を走らせるとクラッシュする事が多い」くらいの、ぼんやりとした物でした。しかし元のツールでは発生しない不具合なので、当然土屋がリファクタリングした過程のどこかで、なにかしらの問題が起きた事になります。

　様々な仮説を立ててバグの原因特定を進めたものの、どうにも分かりません。最後はどうしようもなくなり、「今あるコードを少しずつ元のコードの状態に戻していって、クラッシュが発生しなくなるタイミングを見つける」という、恐ろしく手間のかかる作業を行う事になりました。この「コード巻き戻し戦略」によって、ようやく原因特定に至ったのでした。

　原因は大きく３つあり、そのいずれも「ある特定の処理を行うと、FontEngine内でメモリリークが発生する」という物でした。このメモリリークが遠因となって、最終的にクラッシュに至っていたのです。以下、３つの原因を見て行きます。

※注意※

　FontEngine自体は解析出来ていないので、以下はすべて土屋の推測による物です。予めご了承ください。

原因１：「Save As...」ボタンを外すとクラッシュする

　コードを少しずつロールバックさせた結果、「「Save As...」というボタンをカットするとクラッシュする」事がわかりました。

　……なにそれ！？

　しかも、検証を続けた結果、名前に「.」が含まれるボタンが存在すればクラッシュしない事も分かりました。より不思議な状況ですが、なんとなくこういう事かなという推測が思いつきました。

　以下完全に想像なのですが、恐らくFontEngine内にデバッグ用のコードが残っていて、その中で「Save as...」ボタンがUI上に存在する事を前提に、ボタン名に含まれる「.」で検索して参照を取得しているのだと思われます。しかしボタンは削除されているのでnull参照となり、これがメモリリークを誘発するのでしょう。

　「Save As...」ボタンは土屋のツールには必要ないボタンだったため、改造時の最初期に外していました。まさかそんなところに原因があると思わず、コードのロールバックでも対応を後回しにしていたため、結果的に原因特定が遅くなったのでした。とほほ……。

　UIのボタンのいずれかに「.」が含まれていれば問題無いようなので、残っている「Save」ボタンの末尾にドットを付与して「Save.」ボタンにしました。嘘みたいな話ですが、これでクラッシュは収まったのでした。

原因２：不用意にDebug.Log()を実行するとクラッシュする

　Debug.Log()は、Unityにおけるprintf()デバッグ用メソッドです。簡単にコンソールに内部状態を出力できるので便利ですが、今回はこれも問題になりました。

　ツールの実行中、突然画面上のフォントが壊れる現象が起きました。ツール上の出力だけで無く、コンソールの文字も壊れてしまいます。再起動するしか復旧手段がなく、放置しているとUnityエディタがクラッシュしてしまいます。

（フォントが壊れている例。Unityエディタがこんな状態になるの、中々レアじゃないかと思います。）

　こちらも想像ですが、恐らく、FontEngineの実行中（FontEngineの処理は時間がかかるので、別スレッドで実行します）、FontEngineがUnityの文字描画処理を掴んでいて、その時にDebug.Log()、つまりコンソールへの文字描画処理を試みると、FontEngineと競合が起きて、処理が壊れるのだと思われます。

　元ツールでもDebug.Log()を使っている箇所があるので、この問題を回避する方法もあるのでしょうが、その為には元ツールと同じ処理フローにする必要があり、今回は「Debug.Log()は使わない」という事に決める事で回避しました（回避なのかそれ？）。