10

解決済み：マシンを再起動すると、問題が解決したようです。問題が再発した場合は更新します。

例外が発生した後、特にが絶対パス（）で呼び出されたPython2.6ときにハングするという問題があります。その後、プログラムを終了する必要があります。としてディレクトリ内から、またはとしてルートディレクトリから呼び出された場合、プログラムは正しく終了します。foo.py/home/user/bar/foo.pyctrl+cbar./foo.py./home/user/bar/foo.py

foo.py：

#!/usr/bin/env python2.6
print 'begin'
x = [0, 1, undefined]
print 'x'

また

#!/usr/bin/env python2.6
print 'begin'
raise Exception('stopping here')

sys.exit()また、問題なく正常に動作していることにも言及できます。

#!/usr/bin/env python2.6
import sys
print 'begin'
sys.exit(0)

プログラムの終了に失敗している例外はどうなりますか？これはおそらく私の構成に固有です。どこから解決策を探し始めればよいですか？

編集： execfile('/home/user/bar/foo.py')インタラクティブモードを実行している場合は正常に動作します。さらに、実行nohup /home/user/bar/foo.py &すると、プロセスがハングし、強制終了する必要があります。

CentOSリリース6.3（最終版）を実行しています。この問題は常に存在するとは限りませんでした。これは、週末の約1か月前に始まったばかりです（当時、私はマシンを使用していませんでした）。

更新：GDBを使用したデバッグでは、バックトレースはを指しlibpthread.so.0ます。

#0  0x000000364340e890 in __connect_nocancel () from /lib64/libpthread.so.0
#1  0x00007ffff18960d8 in ?? () from /usr/lib64/python2.6/lib-dynload/_socketmodule.so
#2  0x00007ffff189815c in ?? () from /usr/lib64/python2.6/lib-dynload/_socketmodule.so
#3  0x00007ffff7d0a706 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#4  0x00007ffff7d0c797 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#5  0x00007ffff7d0abe4 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#6  0x00007ffff7d0bccf in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#7  0x00007ffff7d0bccf in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0
#8  0x00007ffff7d0c797 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0
#9  0x00007ffff7c9adb0 in ?? () from /usr/lib64/libpython2.6.so.1.0
#10 0x00007ffff7c70303 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0
#11 0x00007ffff7d04dd3 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0
#12 0x00007ffff7d28cd2 in PyErr_PrintEx () from /usr/lib64/libpython2.6.so.1.0
#13 0x00007ffff7d29297 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.6.so.1.0
#14 0x00007ffff7d35c32 in Py_Main () from /usr/lib64/libpython2.6.so.1.0
#15 0x000000364281ecdd in __libc_start_main () from /lib64/libc.so.6
#16 0x0000000000400649 in _start ()

誰かがこれが何を意味するのか知っていますか？

4

4 に答える 4

1

この正確な問題は、RHEL6マシンでしばらくの間私を悩ませてきました。場合によっては、例外によってハングが発生します。実際、私はあなたのコードを逐語的に取り、症状を再現することができました。

abrtdの回答のおかげで、abrt-addon-pythonパッケージがインストールされ、abrt_exception_handler.pyがsite-packagesの場所に配置され、Pythonの起動時に呼び出されることがわかりました。このファイルは、ソケットを使用してabrtデーモンに接続するsys.excepthook関数をオーバーライドします。詳細については、 ABRTProjectDocを参照してください。

Pythonの呼び出しに-Sを追加すると、ハングが防止されることを確認しました。ただし、-Sオプションを使用すると、起動時にすべてのサイトパッケージがインポートされなくなるため、これは適切なソリューションではありません。

より良い解決策は、Pythonコードに以下を追加することです。

import sys
sys.excepthook = sys.__excepthook__

これにより、元の例外フックが復元され、ハングが防止されます。

于 2015-05-28T22:53:51.587 に答える
0
  • sys.path非絶対ディレクトリを調べてください。
  • gdbなどのデバッガーでいつでも侵入できます
  • 時々私はPYTHONSTARTUP何かを持っているので、インタラクティブインタプリタは別のことをします...
  • straceあなたの友達にもなれます
于 2012-10-13T04:08:55.850 に答える
0
  • マシンを再起動します。

強力な管理者のおかげで、マシンを再起動することができました。すべては順調です。問題が再発した場合は、質問を更新します。

于 2012-10-16T16:18:52.347 に答える
0

私はこの問題を突き止めました。abrtdによって開いたままにされたソケットに書き込もうとしています。

abrtdを再起動すると、問題が修正されました。これが、マシンの再起動が機能した理由です。しかし、問題の根本的な原因は見つかりませんでした。

于 2013-02-05T16:25:12.973 に答える