QuickRunで落ちるらしい

koron commented 13 years ago

kaoriya版Window最新でQuickRunを使うと落ちると報告があった。 2chのソフトウェア板のvimスレ。

http://hibari.2ch.net/test/read.cgi/software/1314189326/29n より転載

Vimは香り屋さんの最新版（7.3）Windows 32bit版で、OSはWindows Vistaです。 VimでもgVimでも落ちました。

ファイルタイプ問わず、 \r や :QuickRun などでquickrunを実行すると落ちます。編集中のファイルでも確認ダイアログなどは出ずに強制終了します。

quickrun.vimはthincaさんが作った方を使っています。同名別物のujihisaさんが作った方も試してみたら同じように落ちました。

あらためてVimとquickrunの最新版のみを入れた状態にして試してみても変わりませんでした。

他に何か書いた方がいいこと、試したらいいことあれば教えて下さい。

mattn commented 13 years ago

読んで分かった点

KaoriYa 最新版（7.3）Windows 32bit版
Windows Vista
設定ファイルに非依存
vimのバージョンに非依存
vim/gvimに非依存
thinca版/ujihisa版に非依存
ファイルタイプに非依存
編集中のファイルでも確認ダイアログなどは出ずに強制終了

mattnの見解

runnerが知りたい。

:QuickRun -runner xxx

でshell,vimproc,remote,system,pythonを試してどれで落ちるかやって欲しい。で、僕が思うにこの中でvim巻き添えで落ちる可能性があるとすればvimprocかpythonって所だろうか。まぁどっちも結構枯れてるので他の要因かもしれないけど。

koron commented 13 years ago

これ、巻き込むにしてもthinca版/ujihisa版に非依存で発生しているのが解せない。巻き込むってことは@mattnさんの言うとおり、vimprocかpythonなんだろうけど、それってujihisa版にも共通しているのかしら?

全然違う目線で見ると、どちらも多くの行を連結してDictを構築している、という共通点は見られるが…

thinca commented 13 years ago

見たところ、if_python のロードで死んでるようです。quickrun は初回ロード時に if_python 使うので、実行時というよりはロード時に落ちてるのかと。

thinca commented 13 years ago

ujihisa版とは言ってますが、今 ujihisa さんのリポジトリの最新は thinca 版の古い版になってますね。これ使ったとしたら構造は大して変わらないかと。

koron commented 13 years ago

つまりインストールされているpythonが期待されているものとズレているということか。

mattn commented 12 years ago

pythonのdllって、python27.dll とかバージョンが付いてるはずなので期待と違うというのは考えにくいんだけどなー。

thinca commented 12 years ago

32bit/64bit が違うとか。

mattn commented 12 years ago

その後動いたとの事なのでよくわかりませんね。たぶん推測だけになって終らない気がするので、これ閉じませんか？

thinca commented 12 years ago

ですね。再現不可ってことで。

Shougo commented 11 years ago

他にも似たような報告があったので貼っておきます。

https://twitter.com/takkii/status/320400357580734464

https://twitter.com/takkii/status/320401623794999297

この問題ですが、Pythonの64bit/32bitが期待したものとずれてしまっていたのではないでしょうか。 Pythonの64bit/32bitを気にする人は少ないでしょうから。 Vimが64bitなのに、32bitのPythonを呼ぼうとしたのだと思われます。本質的に修正不可ですが、FAQのような形でフォローできると良さそうです。

tyru commented 10 years ago

これ結構前から起きてました。そして今も… Kaoriya最新版 + watchdogs.vim で書き込み時に落ちる

インストールしているPythonのDLLはTortoiseHgのだけみたいです。 $ where python*dll C:\Program Files\TortoiseHg\python27.dll C:\Program Files\TortoiseHg\pythoncom27.dll

Vimのバージョンは

VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 17 2013 02:47:44)
MS-Windows 64-bit GUI version
Included patches: 1-92
Modified by koron.kaoriya@gmail.com
Compiled by koron.kaoriya@gmail.com
Huge version with GUI.  Features included (+) or not (-):
+acl                +digraphs           +kaoriya            +persistent_undo    -tcl
+arabic             +directx            +langmap            -postscript         -tgetent
+autocmd            -dnd                +libcall            +printer            -termresponse
+balloon_eval       -ebcdic             +linebreak          +profile            +textobjects
+browse             +emacs_tags         +lispindent         +python/dyn         +title
++builtin_terms     +eval               +listcmds           +python3/dyn        +toolbar
+byte_offset        +ex_extra           +localmap           +quickfix           +user_commands
+cindent            +extra_search       +lua/dyn            +reltime            +vertsplit
+clientserver       +farsi              +menu               +rightleft          +virtualedit
+clipboard          +file_in_path       +migemo/dyn         +ruby/dyn           +visual
+cmdline_compl      +find_in_path       +mksession          +scrollbind         +visualextra
+cmdline_hist       +float              +modify_fname       +signs              +viminfo
+cmdline_info       +folding            +mouse              +smartindent        +vreplace
+comments           -footer             +mouseshape         -sniff              +wildignore
+conceal            +gettext/dyn        +multi_byte_ime/dyn +startuptime        +wildmenu
+cryptv             +guess_encode       +multi_lang         +statusline         +windows
+cscope             -hangul_input       -mzscheme           -sun_workshop       +writebackup
+cursorbind         +iconv/dyn          +netbeans_intg      +syntax             -xfontset
+cursorshape        +insert_expand      -ole                +tag_binary         -xim
+dialog_con_gui     +jumplist           +path_extra         +tag_old_static     -xterm_save
+diff               +keymap             +perl/dyn           -tag_any_white      +xpm_w32
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$HOME\vimfiles\vimrc"
 3rd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
    user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
    system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32   -DFEAT_CSCOPE -DFEAT_NETBEANS_INTG   -DFEAT_XP
M_W32  /DMODIFIED_BY=\"koron.kaoriya@gmail.com\" /DDYNAMIC_MSVCRT_DLL=\"msvcr100.dll\" /DGETTEXT_DLL=\"intl.dll\" /
D_BIND_TO_CURRENT_VCLIBS_VERSION=1 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 /Fo.\ObjGXULYHRAMD64/ /Ox /GL -DNDEBUG /MD
 -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_W32 -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -
DDYNAMIC_MIGEMO -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua51.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_P
YTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python33.dll\" -DFEAT_PERL -DDY
NAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl516.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_VER=20 -DDYNAMIC_RUBY_DLL=\
"x64-msvcrt-ruby200.dll\" -DFEAT_HUGE /Fd.\ObjGXULYHRAMD64/ /Zi
Linking: link /RELEASE /nologo /subsystem:windows /LTCG:STATUS oldnames.lib kernel32.lib advapi32.lib shell32.lib g
di32.lib  comdlg32.lib ole32.lib uuid.lib /machine:AMD64 /nodefaultlib gdi32.lib version.lib   winspool.lib comctl3
2.lib advapi32.lib shell32.lib  /machine:AMD64 /nodefaultlib msvcrt.lib   user32.lib   /nodefaultlib:lua51.lib   /n
odefaultlib:python27.lib /nodefaultlib:python33.lib    WSock32.lib ..\..\contrib\xpm\x64\lib\libXpm.lib /PDB:gvim.p
db -debug

tyru commented 10 years ago

実行可能ファイル（exeやdll）が64bit版か32bit版か判別する方法

バイナリエディタで、調査したい実行可能ファイルを開いて、「0x50450000 (PE\0\0)」となっているバイト列の隣の4バイトが、「0x4C01」なら 32-bit x86 用の実行可能ファイル、「0x6486」なら 64-bit amd64 用のファイルとの事でした。

この方法で試してみた所、両方とも64bit版DLLでした。（OSはWindows 7 Professional 64bit）

python27.dll pythoncom27.dll

tyru commented 10 years ago

ちなみに Kaoriya最新版 + watchdogs.vim で書き込み時に落ちるのコメント欄で @osyo-manga さんに教えてもらったのですが、:python print 42だけで落ちる状況です。コメント欄で @osyo-manga さんに教えてもらった通り、Pythonを入れれば直るのかもしれません。

ynkdir commented 10 years ago

ちょっと前に vim の ML でそんな話がありました。そのときは Mercurial 付属の python27.dll が原因でした。いわゆる標準外の python dll があるときに発生して落ちるというか python がエラーメッセージを出力して exit() します。 CUI の vim.exe だと python の出力が見れると思います。ライブラリがロードできないとかなんかそんなメッセージだった気がします。 exe化みたいなやつで固めた python アプリは特殊なローダでなにやらやってたと思うのでそれ系かなと。

tyru commented 10 years ago

なるほど… それだと、特殊でない通常のPython DLLをPATHの先頭に置いて先にロードさせるようにしたら今度はMercurialやらToirtoiseHgが正常に動かなくなりそうで怖いですね… なんでexe化するツールは通常のPythonに付いてくるDLLと同じファイル名にしちゃったんだろう…

tyru commented 10 years ago

先にロードさせるようにしたら今度はMercurialやらToirtoiseHgが正常に動かなくなりそうで怖いですね…

これ調べたら動かなくなるってことはないみたいですね。アプリケーションのロード元ディレクトリとカレントディレクトリはPATHより優先されるんですね。

http://msdn.microsoft.com/ja-jp/library/cc429241.aspx

アプリケーションのロード元ディレクトリ

カレントディレクトリ

Windows 95/98：Windows のシステムディレクトリ。このディレクトリのパスを取得するには、関数を使います。 Windows NT/2000：Windows の 32 ビット版システムディレクトリ。このディレクトリのパスを取得するには、GetSystemDirectory 関数を使います。このディレクトリの名前は、SYSTEM32 です。

Windows NT/2000：Windows の 16 ビット版システムディレクトリ。このディレクトリのパスを取得する Win32 関数はありませんが、このパスも自動的に検索の対象となります。このディレクトリの名前は、SYSTEM です。

Windows ディレクトリ。このディレクトリのパスを取得するには、関数を使います。

環境変数 PATH に記述されている各ディレクトリ

tyru commented 10 years ago

@koron Kaoriya Vim側で、vim.exeと同じディレクトリにPythonのDLL含めるようにするといった予定はないのでしょうか？ +python/dynでコンパイルしてるのでDLLがないと使えないと思うのですが、ファイルサイズの関係ですか？

koron commented 10 years ago

python を含める予定はないです。理由は python.org から DL できるから。

tyru commented 10 years ago

@koron 了解です。 2014/07/16 1:37 "MURAOKA Taro" notifications@github.com:

python を含める予定はないです。理由は python.org から DL できるから。

— Reply to this email directly or view it on GitHub https://github.com/vim-jp/issues/issues/66#issuecomment-49058824.

ynkdir commented 10 years ago

たしか dll 自体は標準のと同じでした。余談ですが。

tyru commented 10 years ago

Python2とPython3を両方インストールしてみましたが、結局問題が解決しなかったので報告しておきます。 (起きた事をそのまま報告しているので長くてすみません)

python2 C:\Python27\DLLs\python3.dllにDLLがあった

python3 C:\Python34\DLLs\にもどこにもPython DLLがない

両方インストールしても下記の状況のまま変わらず python2: :python print 42 で落ちる python3: :python print(42) で以下のように言われる

E370: Could not load library python34.dll E263: Sorry, this command is disabled, the Python library could not be loaded.

この時のDLL検索結果(cmd.exeで確認)

C:\Users\takuya>where python*.dll
C:\app\bin\python34.dll

ここでNyaosシェルでは

$ where python*.dll
C:\Windows\System32\python27.dll
C:\Windows\System32\python34.dll
C:\Program Files\TortoiseHg\python27.dll
C:\Program Files\TortoiseHg\pythoncom27.dll

と表示されたので、C:\Windows\System32にDLLがあるように見えるのですが、これはNyaosからでしか見れませんでした。エクスプローラからはcmd.exeの結果通り、ファイルの存在が確認できませんでした。フォルダオプションで下記のチェックもオンにしてあります。

隠しファイル、隠しフォルダー、隠しドライブを表示する→オン
保護されたオペレーティングシステムファイルを表示しない→オン

また、上で引用したwhereコマンドや、 dirコマンドなどの外部コマンドからも DLLが見えるのも謎です。 (lsはNyaosの内部コマンド)

[C:\Users\takuya]
$ dir C:\Windows\System32\python27.dll
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は D8F9-EC99 です

C:\Windows\System32 のディレクトリ

2014/06/30  16:03         2,454,016 python27.dll
              1 個のファイル           2,454,016 バイト
              0 個のディレクトリ  35,151,675,392 バイトの空き領域
[C:\Users\takuya]
$ ls C:\Windows\System32\python27.dll
C:\Windows\System32\python27.dll
[C:\Users\takuya]
$ ls C:\Windows\System32\python27.dl
C:\Windows\System32\python27.dl: not found.

ここで一旦Windowsを再起動して再度確認しようと思いました。

下から2つのDLLをデスクトップにフォルダを作りそこに退避させ、
C:\Python27\DLLs\python3.dllをPATHの通った場所にコピーし
python34.dllにリネームし
Windowsを再起動した

再起動時にpython27.dllが見つからないよ！とTortoiseHgのダイアログボックスが出る Vimからも :python print 42で落ちなくなり、下記のエラーメッセージが出るようになった。

E370: Could not load library python27.dll E263: Sorry, this command is disabled, the Python library could not be loaded.

しかしpython34.dllはPATHに置いているはずなのに、なぜか

:python print(42)

でも上記のエラーが出る(DLLが見つからない)。 $PATHの値を見てもちゃんとpython34.dllを置いた箇所にPATHが通っている。この時のwhereコマンドでのDLL検索結果。 (C:\app\binはPATHの通った場所)

$ where python*.dll
C:\Windows\System32\python27.dll
C:\Windows\System32\python34.dll
C:\app\bin\python34.dll

ynkdir commented 10 years ago

インストールした python は 64bit 版ですか？

tyru commented 10 years ago

すみません。多分32bit版でした。単純にトップページのボタンからダウンロードしたのですが、ファイル名にamd64がついてないのでおそらく32bit版だと思います。こっちのページの「Python 3.4.1 Windows X86-64 MSI Installer」てリンクからだとファイル名がpython-2.7.8.amd64.msiでしｔ…あれ！？同じURLなのに違う内容が見えてる…(リファラでも見てるのか…？) う、ひとまず64bit版でインストールしなおしてみます…

32bit版をダウンロードしてしまったページ

トップページ

64bit版をダウンロードしたページ

こっちのページ

tyru commented 10 years ago

あ、よく見たらURL違った… sがない… https://www.python.org/downloads/ https://www.python.org/download/

k-takata commented 10 years ago

C:\Windows\System32にDLLがあるように見えるのですが、

32bitプロセスからの実行結果がそうだったのであれば、実体は C:\Windows\SysWOW64 にあります。なお、32bitプロセスから C:\Windows\Sysnative にアクセスすると、64bit向けの C:\Windows\System32 の中身を見ることができます。

tyru commented 10 years ago

@k-takata うっ…なるほどです。 Vistaら辺からそういう辺な見え方するようになったんでしたっけ… C:\Program FilesとC:\Program Files (x86)とか…

tyru commented 10 years ago

結果としては、 @ynkdir さんの言う通りに64bit版をインストールしたら:pythonコマンドも:python3コマンドも無事使えるようになりました。ありがとうございました。

tyru commented 10 years ago

まとめました。 Vimが落ちる時はif_python等を疑ってみよう

koron commented 10 years ago

どこで落ちてるんだろ?Vim側ならなにか対策できても良さそう。

tyru commented 10 years ago

gdbとか使えば特定できるんでしょうか？ WindowsでVimのデバッグ環境のセットアップ方法が分かりません…

Shougo commented 10 years ago

Vim がやるとすれば、VimがDLLを自前でパス解決してオープンしてみてヘッダをチェックするとかでしょうか。こういうことは OS がやってくれても良さそうですが。

ynkdir commented 10 years ago

確認はしてませんがこれだと思います。

Python-2.7.8/Python/pythonrun.c

/* Import the site module (not into __main__ though) */

static void
initsite(void)
{
    PyObject *m;
    m = PyImport_ImportModule("site");
    if (m == NULL) {
        PyErr_Print();
        Py_Finalize();
        exit(1);
    }
    else {
        Py_DECREF(m);
    }
}

koron commented 10 years ago

再現手順は 64bit 版のVimから 32bit版のpython.dll をロード(実行)するであってますかね?

仮にそうだとしたら、ロード自体ができちゃうのが問題の根源な気がします。ってかできるの?w

koron commented 10 years ago

おおう。なんも言わずに落ちた。以下、詳細な状況

Vim は64bit
Python は 2.7.6/3.4.0 の 32/64bit 系4バージョンインストール済み
Path は 2.7.6 の 64bit に通ってる

手順:

C:\Windows\System32\python27.dll を python27.dll~ にリネームして読めないように
gvim を起動して py import sys; print(sys.version) を実行
落ちた。システムデバッガも拾ってくれない

備考:

python34.dll のほうで同様に py3 import sys; print(sys.version) した時は、落ちずにDLLが読めないとエラーが出た

thinca commented 10 years ago

これ Closed になってますけど再オープンした方がいい流れです?

koron commented 10 years ago

今、新しく作ってます。

thinca commented 10 years ago

了解。(タイトルがアレだと思っていたけど作り直すならいいか)

koron commented 10 years ago

キャッチーなタイトルにしてみたw

ynkdir commented 10 years ago

tyru さんの件で python インストールしてあるのに site がないのはおかしいなと調べてたんですが

たしか dll 自体は標準のと同じでした。余談ですが。

これ間違いで py2exe は python27.dll に細工してました。 python27.dll の winver(1000) というリソースを変更してます。 python はレジストリの HKLM\Software\Python\PythonCore{WINVER} に PYTHONPATH を取りにいくので py2exe の dll は普通には使えない。

0xBADDCAFE commented 10 years ago

https://github.com/vim-jp/issues/issues/66#issuecomment-49540814

これですが、MSVC でビルドしたものであればデバッグビルド DEBUG=yes したバイナリを起動して、VisualStudio から外部プロセスにアタッチすればブレーク・ステップ実行などのデバッグ機能は出来ました。ファイル→開く等で VisualStudio に Vim のソースを適当に開いてブレークを貼れば止まってくれます。

私も手探りでやったので、もっといい方法というか正しいやり方があれば知りたいです。

koron commented 10 years ago

Windowsではデバッガが拾わない=例外ではなくプログラムでExitしていると推測するべきなので @ynkdir さんが挙げた箇所で引っかかったと考えるのが正しいです。

koron commented 10 years ago

えっと以後、この話題は #594 でお願いします。

0xBADDCAFE commented 10 years ago

すいません。

WindowsでVimのデバッグ環境のセットアップ方法が分かりません…

に反応したつもりでした。

本題 (Python で落ちる) とはちょっとそれた話題かと思ったのであえてそのままこちらに返事していました。気をつけておきます。

vim-jp / issues