2

因此,我在具有相同架构但 C 编译器略有不同的两台不同机器上使用 Python Stackless 和 heapy。Heapy 在第一个上工作得很好,但我在第二个上得到了核心转储。

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);
}
4

4 回答 4

5

将此问题和堆栈跟踪发布到 Guppy 邮件列表。我想说这对于 StackOverflow 的一般人群来说有点过于专业化,无法提供帮助,但如果崩溃严重,开发人员可能会为您指明正确的方向。

于 2011-07-25T20:27:52.173 回答
4

我不知道如何解决这个问题。

调试任何SIGSEGV崩溃的“标准”方法是在调试器(Linux 上的 GDB)下运行程序(在本例中为 python)并获取崩溃堆栈跟踪:

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——您处于调试问题的最佳位置,因为您是唯一可以观察到问题的人。

于 2011-07-24T01:48:05.243 回答
1

作为一种解决方法,请注意堆栈跟踪中的 PyErr_Display。 http://www.google.com/codesearch#-2BKs-LW4I0/trunk/python/src/Python/pythonrun.c&q=function:PyErr_Display&type=cs&l=1186

会不会发生一些错误?如果段错误是其中一个软件中的编码错误,也许如果你摆脱了 python 异常,你就自由了。我建议尝试使用 gdb(或 ddd)找出发生了什么异常

于 2011-07-26T22:18:53.570 回答
-2

Why are you using two differentversions of Python (release27-maint) that were built with two different compilers? It is not that difficult to build Python so that you have consistent versions on both machines, built with the same GCC version. If the machine architectures are different, you can cross-compile if you need to.

Clearly, one of these builds has a bug. If both machines are the same architecture you could just take the working Python and copy it to a user directory on the other machine.

If an app is important to you, always build your own Python so that you have control and consistency.

于 2011-08-02T01:11:22.983 回答