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とか出てたし、ファイル数開きすぎとか、スタックオーバーフローとか、その辺が臭いような気がしているので、その辺をもっと調べてみよう。
もし、どなたか情報お持ちのかたは教えていただけると幸いです。