【GIMP】PNGを開いて落ちる原因はサムネイル生成の不具合だった（GEGL、babl）

iPhoneで撮ったスクリーンショットをGIMP 3.2.4で開こうとすると、画像が表示される前に落ちました。クラッシュログをたどると、止まっていたのはPNGの読み込みではなく、レイヤーの縮小プレビューを作る処理です。
設定からレイヤーとチャンネルのプレビューをオフにすると、同じファイルが問題なく開くようになりました。ファイルの破損でもMac本体の故障でもありません。
それでも落ちるなら、GEGLを1スレッドに制限して起動する、3.2.2へ戻す、macOSの「プレビュー」でTIFFに書き出してから開く、という手が残っています。
同じ関数列のクラッシュ報告は2026年1月に出ていて、3.2.4で新しく生まれた不具合ではなさそうです。

1. 落ちているのは読み込みではなく縮小プレビュー

iPhoneのスクリーンショットをGIMPのウィンドウに放り込むと、読み込みの進捗が一瞬だけ出て、そのままアプリが消えました。 macOSのクラッシュレポートが立ち上がる、あの流れです。別のスクリーンショットでも同じ。

最初に疑ったのは、ファイルそのものでした。ところがクラッシュログを開くと、いちばん上に近い場所にあったのは gimp_drawable_get_sub_preview_async_func という関数です。そこから GEGL の縮小処理へ降り、さらに babl の色変換へ降りたところで止まっています¹。

PNGをデコードする関数は、この列のどこにも出てきません。つまり画像は読めている。読めた画像を縮めてサムネイルにするところで落ちていたわけです。

1.1. GEGLとbablという二つの下請け

GIMPは、画像に対する演算そのものを自前で全部やっているわけではありません。 GEGL（Generic Graphics Library：ジェネリック・グラフィックス・ライブラリ）が実際の画素の計算を引き受け、babl（バブル）が色の形式と色空間の変換を引き受けています²。ぼかしも縮小も合成も、GIMPはGEGLに依頼を出す側です。

縮小は単純な処理に見えて、色空間を無視すると結果が暗くなります。 sRGBの値をそのまま平均してはいけないので、いったんリニアな表現に直してから平均し、また戻す。この行き来を担当するのがbablで、ログに出てきた babl_fish_path_process は、ある色形式から別の色形式へ至る変換経路を実行する部分です。

GEGL側の gegl_downscale_2x2_generic2 は、2×2の画素を平均して縦横半分にする処理です。これを何度か繰り返して、レイヤーダイアログに並ぶ小さな絵まで落とします。関数名に async が付いているとおり、この作業はメインスレッドではなく別のワーカースレッドで走ります。

1.2. SIGBUSはスタックの端で起きた

ログの末尾にあった信号は SIGBUS でした。不正なメモリアクセスというと SIGSEGV（Segmentation Fault：セグメンテーション違反）を思い浮かべますが、SIGBUSはアドレス自体は筋が通っているのに、そのアドレスへのアクセスがハードウェア的に成立しない場合に出ます³。

今回の到達先は STACK GUARD と書かれた領域でした。スタックガードは、スレッドに割り当てられたスタックの末端に置かれる、触れば必ず失敗するページです。スタックが想定を超えて伸びたことを、その場で検出するために置かれています。

要するにスタックが足りなくなっている。 GEGLのワーカースレッドは、メインスレッドほど広いスタックを与えられていません。そこでbablが変換経路を探しながら深く潜ると、端に届いてしまうのだと思います。メモリ不足とは別の話なので、RAMを増やしても直りません。

2. プレビューを切ると落ちなくなる

回避の手順は短いです。 PNGを開かずにGIMPだけを起動し、「編集」から「設定」を開いて「インターフェース」を選びます。そこにある「レイヤーとチャンネルのプレビューを有効にする」をオフにして、GIMPを再起動します⁴。

この設定は、レイヤーダイアログやチャンネルダイアログに並ぶ小さな縮小画像を作らせないためのものです。縮小画像を作らなければ、gimp_drawable_get_sub_preview_async_func から始まる経路そのものを通りません。落ちる場所を直すのではなく、通らないようにする対処。

実際、これで同じスクリーンショットが普通に開きました。レイヤーが増えたときに絵柄で見分けられなくなるので、名前を付ける手間は増えます。それでも落ちるよりはましです。

2.1. それでも落ちるときの手

設定を変えても落ちる場合は、ターミナルから環境変数を付けて起動する方法があります。

GEGL_THREADS=1 /Applications/GIMP.app/Contents/MacOS/gimp
Code language: Bash (bash)

GEGL_THREADS=1 は、GEGLが使う処理スレッドを1本に制限する指定です⁵。ワーカースレッドに仕事を投げる形自体が減るので、スタックの狭いスレッドで色変換が走る場面を避けられることがあります。

確実性を優先するなら、更新前のGIMP 3.2.2へ戻すのが早いです。クラッシュログにx86_64と出ていればIntel版なので、公式アーカイブの gimp-3.2.2-x86_64.dmg が対象になります⁶。最新の安定版は3.2.4ですが、アーカイブには旧版も残されています⁷。

急いで1枚だけ処理したいなら、macOSの「プレビュー」でスクリーンショットをTIFFに書き出し、それをGIMPで開く手もあります。 JPEGでも開けますが、書き出しのたびに画質が落ちる。編集の元にするならTIFFの方が安全です。

3. いつからあるバグなのか

まったく同じ症状の公開報告は、探しても多くありません。最も近いのは2026年1月22日に公開されたmacOS版GIMP 3.0系の記録で、ほぼすべてのPNGでクラッシュすること、SIGBUSであること、babl_fish_path_process から gegl_downscale_2x2_generic2 を経て gimp_drawable_get_sub_preview_async_func に至る関数列であること、プレビューをオフにすると直ることまで一致しています⁸。

フォーラムには2025年7月30日に「macOSでPNGを開くとクラッシュする」という投稿もあります⁹。ただしこちらはGIMP 2.10で、カラープロファイルを変換するか維持するかを選んだ直後に落ちるという内容です。クラッシュログが載っていないため、同じ原因だとは言えません。

GIMP 3.0の正式公開が2025年3月16日、3.2.4の公開が2026年4月19日¹⁰。確認できる材料からは、発生時期を2025年3月から2026年1月のどこか、というところまでしか絞れませんでした。少なくとも、3.2.4で新たに混入したものではなさそうです。

3.2.4のリリースノートを読んでも、このクラッシュを修正したという記述は見当たりません。まだ直っていないのか、正式な不具合として整理されていないのか、外からは判断できないところです。

落ちた瞬間は、ファイルが壊れたのかMacが壊れたのかと身構えました。ログの関数名を上から順に読むだけで、疑う範囲はかなり狭まります。アプリが落ちたら、まずログを開く。それだけで、直し方が設定一つだったと分かることもあります。

GEGLは、GIMPの内部で画素の演算を担当するために開発された画像処理ライブラリです。 – GEGL
bablは画素形式の変換を担当するライブラリで、ある形式から別の形式へ至る変換経路そのものを「fish」と呼びます。 – babl
Appleの資料でも、メモリアクセス関連のクラッシュはEXC_BAD_ACCESSとして扱われ、対応する信号によって原因の種類が分かれると説明されています。 – Investigating memory access crashes
GIMPのマニュアルでも、この設定は「Enable layer & channel previews」として説明されていて、大きな画像で動作が重いときに切ることが挙げられています。 – 6.10. Interface
GEGLの環境変数一覧では、GEGL_THREADSは1から64まで指定でき、1にすると単一スレッド処理になると書かれています。 – environment
公式のダウンロードアーカイブには、3.2系のIntel版とApple Silicon版のdmgが版ごとに残されています。 – Index of /gimp/v3.2/macos/
3.2.4は2026年4月19日公開の安定版です。 – GIMP 3.2.4 Released
同じ関数列とSIGBUSが記録されていて、プレビューを無効化すると開けるようになる点まで共通しています。 – 【GEGL, babl】GIMPでPNGを開くとmacOSでクラッシュした
GIMP 2.10で、カラープロファイルの扱いを選んだ直後に落ちるという報告です。 – GIMP crashes when opening png on mac
GIMP 3.0は、GTK3への移行と高ビット深度対応を含む大きな更新として公開されました。 – GIMP 3.0 Released