New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

:terminal内のcmd.exeを巻き込んで終了するプログラムがある #1072

Open
ichitera opened this Issue Aug 17, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@ichitera

ichitera commented Aug 17, 2017

質問・報告の内容

もしかするとバグかもしれない動作を見つけたので報告します。

:terminalで起動したcmd.exeの中で、
gdbのTUIモードに移行しようとすると:terminalが終了します。

もしもgdbがTUIモードに対応していなくても、
:terminalが終了するのではなく、cmd.exeのプロンプトに戻ってきてほしいと思っています。

手順は次です。

  1. vim -u NONE -Nにてvim.exeを起動
  2. :term<CR>を押下
  3. (terminalのcmd.exe中で) gdbを実行
  4. gdb起動後、<C-X><C-A>を押下してTUIモードへ
  5. (:terminalが終了)

動かしているアニメーションが次です。

animation

Vimのバージョン

( :version で確認できます)

8.0.938 (tuxproject.de より入手したもの)

OSの種類/ディストリ/バージョン

(なるべく詳しく書いてください 記述例:)

  • Windows 10 HOME 64bit (10.0.15063)

使用している or 関係していそうなプラグイン

  • gdb 8.0 (msys2にてpacman -S mingw-w64-x86_64-gdbで入手したもの)
  • 作業時の%PATH%: C:\Windows\System32;C:\vim;C:\msys64\mingw64\bin;C:\msys64\usr\bin;

その他

(関連して何か気がついたこと、気になることがあればココに書いてください)

gdbのTUIモードですが、:terminalではなく、cmd.exeの中で実行したときは動いています。

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 17, 2017

Member

詳しい説明ありがとうございます。

Member

mattn commented Aug 17, 2017

詳しい説明ありがとうございます。

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 17, 2017

Member

再現しました。vim/gvim 上で試してみましたが、それでも間にいる cmd.exe を巻き込んで死んでいる様です。

Member

mattn commented Aug 17, 2017

再現しました。vim/gvim 上で試してみましたが、それでも間にいる cmd.exe を巻き込んで死んでいる様です。

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 17, 2017

Member

物は試しにと思い、Visual Studio Code の中のコンソールで gdb を起動してやってみましたが、そちらでも再現しました。という事で vim 単独犯では無い事は分かりましたが、もし何らかの方法で修正可能ならば直したいのでしばらく開いたままにしておきます。

Member

mattn commented Aug 17, 2017

物は試しにと思い、Visual Studio Code の中のコンソールで gdb を起動してやってみましたが、そちらでも再現しました。という事で vim 単独犯では無い事は分かりましたが、もし何らかの方法で修正可能ならば直したいのでしばらく開いたままにしておきます。

@ichitera

This comment has been minimized.

Show comment
Hide comment
@ichitera

ichitera Aug 17, 2017

再現確認をありがとうございます。開いたままの件承知しました。

ichitera commented Aug 17, 2017

再現確認をありがとうございます。開いたままの件承知しました。

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 17, 2017

Member

どうやら winpty が落ちてるのが分かりました。winpty-debugserver.exe を起動し、別のコマンドプロンプトで環境変数 WINPTY_DEBUG=trace に設定、その状態で vim or gvim から :terminal を起動し、gdb から例のキーを叩いたらトレースログに以下が出ました。

[75443.871 winpty-agent.exe,p1032,t6352]: Assertion failed: conout != INVALID_HANDLE_VALUE, file src/agent/Win32ConsoleBuffer.cc, line 39

この箇所は CONOUT$ を開き直している箇所でした。

std::unique_ptr<Win32ConsoleBuffer> Win32ConsoleBuffer::openConout() {
    const HANDLE conout = CreateFileW(L"CONOUT$",
                                      GENERIC_READ | GENERIC_WRITE,
                                      FILE_SHARE_READ | FILE_SHARE_WRITE,
                                      NULL, OPEN_EXISTING, 0, NULL);
    ASSERT(conout != INVALID_HANDLE_VALUE);
    return std::unique_ptr<Win32ConsoleBuffer>(
        new Win32ConsoleBuffer(conout, true));
}

で、推測なのですがおそくら gdb が tui モードに移る際に CONOUT$ を排他モードで開いていて、winpty-agent.exe がハンドルを作れなくて落ちるという動作なのではないかと思います。

マジか、そんな gdb おらんやろと思ってソース見てみたら...

https://github.com/bminor/binutils-gdb/blob/0749542484129e77a30f1089d6d671197be5035f/gdb/windows-nat.c#L2059-L2060

おーまーえーかー。

Member

mattn commented Aug 17, 2017

どうやら winpty が落ちてるのが分かりました。winpty-debugserver.exe を起動し、別のコマンドプロンプトで環境変数 WINPTY_DEBUG=trace に設定、その状態で vim or gvim から :terminal を起動し、gdb から例のキーを叩いたらトレースログに以下が出ました。

[75443.871 winpty-agent.exe,p1032,t6352]: Assertion failed: conout != INVALID_HANDLE_VALUE, file src/agent/Win32ConsoleBuffer.cc, line 39

この箇所は CONOUT$ を開き直している箇所でした。

std::unique_ptr<Win32ConsoleBuffer> Win32ConsoleBuffer::openConout() {
    const HANDLE conout = CreateFileW(L"CONOUT$",
                                      GENERIC_READ | GENERIC_WRITE,
                                      FILE_SHARE_READ | FILE_SHARE_WRITE,
                                      NULL, OPEN_EXISTING, 0, NULL);
    ASSERT(conout != INVALID_HANDLE_VALUE);
    return std::unique_ptr<Win32ConsoleBuffer>(
        new Win32ConsoleBuffer(conout, true));
}

で、推測なのですがおそくら gdb が tui モードに移る際に CONOUT$ を排他モードで開いていて、winpty-agent.exe がハンドルを作れなくて落ちるという動作なのではないかと思います。

マジか、そんな gdb おらんやろと思ってソース見てみたら...

https://github.com/bminor/binutils-gdb/blob/0749542484129e77a30f1089d6d671197be5035f/gdb/windows-nat.c#L2059-L2060

おーまーえーかー。

@mattn

This comment has been minimized.

Show comment
Hide comment
Member

mattn commented Aug 17, 2017

@ichitera

This comment has been minimized.

Show comment
Hide comment
@ichitera

ichitera Aug 18, 2017

バグの所在がわかってスッキリです。
本件Vimのバグでなくgdbが修正されれば治りそうかと思うのですが、Issueの閉じ時はMemberの方におまかせしたら良いのでしょうか。

ichitera commented Aug 18, 2017

バグの所在がわかってスッキリです。
本件Vimのバグでなくgdbが修正されれば治りそうかと思うのですが、Issueの閉じ時はMemberの方におまかせしたら良いのでしょうか。

@mattn

This comment has been minimized.

Show comment
Hide comment
@mattn

mattn Aug 22, 2017

Member

はい。こちらにお任せ下さい。

Member

mattn commented Aug 22, 2017

はい。こちらにお任せ下さい。

@ichitera

This comment has been minimized.

Show comment
Hide comment
@ichitera

ichitera Aug 26, 2017

ありがとうございます。よろしくお願いします。

ichitera commented Aug 26, 2017

ありがとうございます。よろしくお願いします。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment