ぐるっとぐりっど

日曜プログラマがいろいろ試してみたことを、後の自分のためにまとめておく場所

Windowsのgnupackのemacsで、package.elを使って大きなelispをバージョンアップするとプロセスがダウンする問題

はじめに

gnupackでemacsを使っているんだけど、org-modeとか、helm-coreとか、yasnippetとか、比較的大きなパッケージを、package.elでバージョンアップ(package-list-packagesで、u→x)すると、なんか知らないけど、emacsがダウンしてしまう。どうせ既知の問題だろうと思って調べてみても何も出てこない。

現時点で解決してないけど、ひとまずmemo

環境

M-x emacs-versionした結果は以下の通り

GNU Emacs 24.5.1 (i686-pc-cygwin) of 2015-11-08 on gnupack

gnupackで独自ビルドしたと聞いているやつ

ためしたこと

直接起動すると、何もわからないままダウンしてしまうので、cygwinのターミナルから開いて再現させてみる。
→ Segmentation Fault 11と出る


core dumpを吐くように設定し、再現させてみる
gdbで開いてみるも、特に情報はなにも出ない


WinDbgで、emacsプロセスにアタッチして、再現させてみる
→ 以下のログが出た。が、よくわからない。。。

Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Module load completed but symbols could not be loaded for path\to\app\cygwin\emacs\bin\emacs.exe
emacs+0x72dda:
00472dda 8903            mov     dword ptr [ebx],eax  ds:002b:ffffffff=????????
0:000:x86> kbnL
 # ChildEBP RetAddr  Args to Child              
WARNING: Stack unwind information not available. Following frames may be wrong.
00 01d19c08 004f51d3 22dbccfc 01d19cc8 00000000 emacs+0x72dda
01 00000000 00000000 00000000 00000000 00000000 emacs+0xf51d3

エラーメッセージから、まずいとこおさわりしてしまっておまわりさんこいつです状態なように見える。
ただ、スタックバックトレース見ても、何もわからんちん状態。そもそもWinDbgやらgdbやらを使ったデバッグには慣れてないので、よくわからない。というか、そもそも解析には、pdbファイルのようなビルド時の情報が必要になるのではあるまいか?

想像と今後の方向

やはりバッファオーバーフローとか、そのへんで変なメモリ触っちゃって落とされた可能性が高いのではないかと想像している。
gnupackを使うまえは、nativeなw32バイナリ版のemacsを使ってたけど、そのときも結構yasnippetをバージョンアップしようとすると、too many open filesとか出てたし、ファイル数開きすぎとか、スタックオーバーフローとか、その辺が臭いような気がしているので、その辺をもっと調べてみよう。

もし、どなたか情報お持ちのかたは教えていただけると幸いです。