1

Glassfishコンテナーで実行されている古いHudsonを備えたWindows 7マシンがあります。これにより、長い cygwin bash スクリプトによって管理されるビルドが実行されます。スクリプトの一部にループが含まれています。

if [ -d "$STASH_DIR" ]; then
    svn status -v images | \
            iconv -f cp1250 -t utf-8 | \
            sed 's+\\+/+g' | \
            grep '^        .*\.\(gif\|png\)$' | \
            while read dummy rev author file; do
        dat=${file%.???}.dat
        if [ -f "$STASH_DIR/$dat.$rev" ]; then
            cp -v "$STASH_DIR/$dat.$rev" "$dat"
        fi
    done || true # Not critical; ignore failures
fi

(大量の画像とそれらを操作するプロセスが非常に遅いため、その結果を別のディレクトリにキャッシュします。プロセスはおそらくはるかに高速になる可能性がありますが、それは別の問題です。)

現在、時折、cpファイルのリストの途中にある がハングします。CPUを消費する無限ループに入り、強制終了する必要があります。私がそうすると、ループが続き、ビルドは正常に終了します。ただし、これは単なるキャッシュであるため、ファイルがコピーされていなくても、ビルドは成功します。

だから私の質問は、これをトラブルシューティングするためにどのようなオプションがありますか? SYSTEM アカウントでサービスとして実行されていますが、私は管理者権限を持っているので、何かをアタッチできるかもしれません。何が役立つかわかりません。そこに Visual Studio があり、そこに任意の cygwin ツールをインストールできますが、バイナリは明らかにデバッグ情報でビルドされていません。

編集：試しました：

  • resmonプロセスが全速力で実行されていることを除いて、興味深いことは何も示していません。
  • 興味深いのは、プロセスがcygwin の ps に従ってbash.exeいるのに、Windows ツールによって報告されているということです。/usr/bin/cp
  • デバッガー（Visual Studio）によると、プロセスにはデバッグ情報がなく（予想される）、cygwin1.dll（ルートフレームのみ）kernel32.dllからコードを実行しているだけntdll.dllです。実行可能ファイル自体を指すフレームはありません。
  • によるとhandle.exe、glassfish のログ ファイル ( C:\glassfishv3\glassfish\domains\domain1\logs\jvm.log) を開いているだけで、それは作業ディレクトリであり、それに加えて何かC:\Windowsと呼ばれるオブジェクトの束だけです。\BaseNamedObjects\

実行しようとしたとき、cp.exeまたは終了時に失敗する可能性がありますが、それを確認/デバッグする方法はまだわかりません。

4

0 に答える 0