python - guppy ( heapy ) という Python ツールを使用する場合の C コードのセグメンテーション違反

Question

そのため、アーキテクチャは同じだが C コンパイラがわずかに異なる 2 つの異なるマシンで、heapy を使用して Python Stackless を使用しています。Heapy は最初のものでは問題なく動作しますが、2 番目のものではコアダンプが発生します。

Python 2.7.1 Stackless 3.1b3 060516 (release27-maint, Jul 20 2011, 13:26:38)
[GCC 3.4.3 (MontaVista 3.4.3-25.0.116.0601565 2006-09-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from guppy import hpy;
>>> h=hpy()
>>> h.heap()
Segmentation fault (core dumped)

この問題に取り組む方法がわかりません。任意の提案をいただければ幸いです。

ご参考までに、これは動作する他のものでどのように見えるかです:

Python 2.7.1 Stackless 3.1b3 060516 (python-2.71:88862M, Jul 21 2011, 16:57:52)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from guppy import hpy;
>>> h=hpy()
>>> h.heap()
Partition of a set of 26124 objects. Total size = 1940540 bytes.
 Index  Count   %     Size   % Cumulative  % Kind (class / dict of class)
     0  11693  45   727628  37    727628  37 str
     1   5848  22   211232  11    938860  48 tuple
     2    324   1   128352   7   1067212  55 dict (no owner)
     3    232   1   122120   6   1189332  61 type
     4    232   1   117184   6   1306516  67 dict of type
     5   1612   6   116064   6   1422580  73 types.CodeType
     6     67   0   107416   6   1529996  79 dict of module
     7   1576   6    88256   5   1618252  83 function
     8    126   0    67440   3   1685692  87 dict of class
     9   1163   4    46520   2   1732212  89 __builtin__.wrapper_descriptor
<94 more rows. Type e.g. '_.more' to view.>

編集：

@Employed Russian が示唆するように、gdb バックトレースは次のとおりです。

Linux(debug)# gdb /x86/bin/python2.7
GNU gdb 6.3 (MontaVista 6.3-20.0.75.0601655 2006-10-01)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-montavista-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run

Starting program: /x86/bin/python2.7
Python 2.7.1 Stackless 3.1b3 060516 (release27-maint, Jul 20 2011, 13:26:38)
[GCC 3.4.3 (MontaVista 3.4.3-25.0.116.0601565 2006-09-20)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from guppy import hpy;
>>> h=hpy()
>>> h.heap()

Program received signal SIGSEGV, Segmentation fault.
0xb7bd5b0f in frame_traverse (ta=0xbfff7d00) at src/heapy/stdtypes.c:320
320     src/heapy/stdtypes.c: No such file or directory.
        in src/heapy/stdtypes.c
(gdb) where
#0  0xb7bd5b0f in frame_traverse (ta=0xbfff7d00) at src/heapy/stdtypes.c:320
#1  0xb7bccb8a in xt_hd_traverse (xt=0x758b0000, obj=0x80e5634,
    visit=0x80e5634, arg=0x80e5634) at hv.c:298
#2  0xb7bccf75 in hv_std_traverse (hv=0x80e5634, obj=0x80e5634,
    visit=0xb7bcee20 <hv_heap_rec>, arg=0xbfff7df0) at hv.c:513
#3  0xb7bd3e6e in rootstate_traverse (ta=0x80e5634) at rootstate.c:281
#4  0xb7bccb8a in xt_hd_traverse (xt=0x758b0000, obj=0x80e5634,
    visit=0x80e5634, arg=0x80e5634) at hv.c:298
#5  0xb7bccf75 in hv_std_traverse (hv=0x80e5634, obj=0xb7bd9600,
    visit=0xb7bcee20 <hv_heap_rec>, arg=0xbfff7df0) at hv.c:513
#6  0xb7bcef24 in hv_heap (self=0xb7b60994, args=0x0, kwds=0x1923cc4d)
    at hv.c:871
#7  0xb7f255bc in PyEval_EvalFrame_value ()
   from /usr/lib/libpython2.7.so.1.0
#8  0xb7f272f2 in PyEval_EvalFrameEx_slp ()
   from /usr/lib/libpython2.7.so.1.0
#9  0xb7f27012 in PyEval_EvalFrame_value ()
   from /usr/lib/libpython2.7.so.1.0
#10 0xb7f272f2 in PyEval_EvalFrameEx_slp ()
   from /usr/lib/libpython2.7.so.1.0
#11 0xb7f27012 in PyEval_EvalFrame_value ()
   from /usr/lib/libpython2.7.so.1.0
#12 0xb7f272f2 in PyEval_EvalFrameEx_slp ()
   from /usr/lib/libpython2.7.so.1.0
#13 0xb7f28426 in slp_eval_frame_newstack ()
   from /usr/lib/libpython2.7.so.1.0
#14 0xb7f271fb in PyEval_EvalFrameEx_slp ()
   from /usr/lib/libpython2.7.so.1.0
#15 0xb7f28b57 in slp_frame_dispatch_top ()
   from /usr/lib/libpython2.7.so.1.0
#16 0xb7f2c12e in slp_run_tasklet () from /usr/lib/libpython2.7.so.1.0
#17 0xb7f28a84 in slp_eval_frame () from /usr/lib/libpython2.7.so.1.0
#18 0xb7f28b08 in slp_eval_frame () from /usr/lib/libpython2.7.so.1.0
#19 0xb7f28a28 in slp_eval_frame () from /usr/lib/libpython2.7.so.1.0
#20 0xb7f20e24 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
---Type <return> to continue, or q <return> to quit---
#21 0xb7f20eb5 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#22 0xb7f4aff8 in PyErr_Display () from /usr/lib/libpython2.7.so.1.0
#23 0xb7f4c93e in PyRun_InteractiveOneFlags ()
   from /usr/lib/libpython2.7.so.1.0
#24 0xb7f4ca86 in PyRun_InteractiveLoopFlags ()
   from /usr/lib/libpython2.7.so.1.0
#25 0xb7f4cdde in PyRun_AnyFileExFlags () from /usr/lib/libpython2.7.so.1.0
#26 0xb7f59b8a in Py_Main () from /usr/lib/libpython2.7.so.1.0
#27 0x0804862a in main (argc=135157300, argv=0x80e5634)
    at ./Modules/python.c:23

EDIT2：詳細：

だからライン

if (PyTuple_Check(co->co_varnames))

ファイル stdtypes.c 内の次の関数でセグメンテーション違反が発生する場所です。

static int
frame_traverse(NyHeapTraverse *ta) {
    PyFrameObject *v = (void *)ta->obj;
    PyCodeObject *co = v->f_code;
    int nlocals = co->co_nlocals;
    **if (PyTuple_Check(co->co_varnames)) {**
        int i;
        for (i = 0; i < nlocals; i++) {
            PyObject *name = PyTuple_GET_ITEM(co->co_varnames, i);
            if (strcmp(PyString_AsString(name), "_hiding_tag_") == 0) {
                if (v->f_local://splus[i] == ta->_hiding_tag_)
                  return 0;
                else
                  break;
            }
        }
    }
    return v->ob_type->tp_traverse(ta->obj, ta->visit, ta->arg);
}

score 5 · Accepted Answer

この質問とスタックトレースをGuppyメーリングリストに投稿してください。これは、StackOverflowの一般的な人々が支援するには少し専門的な問題だと思いますが、クラッシュが多発している場合、開発者はおそらくあなたを正しい方向に向けることができます。

score 4 · Accepted Answer

この問題に取り組む方法がわかりません。

クラッシュをデバッグする「標準的な」方法SIGSEGVは、プログラム (この場合は python) をデバッガー (Linux の GDB) の下で実行し、クラッシュスタックトレースを取得することです。

gdb python
(gdb) run
... when you get python '>>>' prompt, enter the commands which cause crash
... GDB will stop with SIGSEGV
(gdb) where

スタックトレースに表示される内容によっては、根本的な原因について知識に基づいて推測できる場合や、ここにいる誰かが助けてくれる場合があります。

しかし、その情報がなければ、誰も本当にあなたを助けることはできません.

更新: Linux/x86_64 で guppy-0.1.9 をビルドし、Valgrind でクラッシュを引き起こすコマンドを実行しました (私にとってはクラッシュではありません)。エラーは表示されませんでした。

問題は、Python の正確なバージョン、python または guppy のビルドに使用されたコンパイラのバージョン、または環境のいずれかによって引き起こされる可能性があります。これらを変更することをお勧めします (環境を変更するのがおそらく最も簡単です)。問題を解決したり、別のマシンで再表示したりできるかどうかを確認してください。クラッシュが発生する条件を絞り込むことができれば、バグを修正できる可能性が大幅に向上します。

それができない場合は、デバッグで手を汚してください。C問題を観察できるのはあなただけなので、問題をデバッグするのに最適な立場にあります。

score 1 · Accepted Answer

回避策として、スタックトレースの PyErr_Display に注目してください。 http://www.google.com/codesearch#-2BKs-LW4I0/trunk/python/src/Python/pythonrun.c&q=function:PyErr_Display&type=cs&l=1186

なんらかのエラーが発生している可能性はありますか? segfault がいずれかのソフトウェアのコーディングエラーである場合、おそらく Python 例外を取り除くことができれば、問題はありません。gdb（またはddd）を使用して、どの例外が発生しているかを確認することをお勧めします

score -2 · Accepted Answer

2 つの異なるコンパイラでビルドされた 2 つの異なるバージョンの Python (release27-maint) を使用しているのはなぜですか? 同じ GCC バージョンでビルドされた両方のマシンで一貫したバージョンを持つように Python をビルドすることはそれほど難しくありません。マシンのアーキテクチャが異なる場合は、必要に応じてクロスコンパイルできます。

明らかに、これらのビルドの 1 つにバグがあります。両方のマシンが同じアーキテクチャである場合は、動作中の Python を取得して、もう一方のマシンのユーザーディレクトリにコピーできます。

アプリが重要な場合は、常に独自の Python を構築して、制御と一貫性を確保してください。

python - guppy ( heapy ) という Python ツールを使用する場合の C コードのセグメンテーション違反

4 に答える 4

Related

Reference