Segfault in the C code when using a Python tool called guppy ( heapy )

So I am using Python Stackless with heapy on two diffrent machines with the same architectures but slightly different C compilers. Heapy works perfectly fine on the first one, but I get a core dump on the second one.

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)

I don't know how to tackle this problem. Any suggestions appreciated.

In case you were wondering, this is how it looks in the other one that works:

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.>

EDIT:

Ok so as suggested by @Employed Russian, here is the gdb backtrace:

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 c开发者_JS百科onditions.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: more info:

so the line

if (PyTuple_Check(co->co_varnames))

is where the segfaults happen in the following function inside file 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);
}

Post this question and the stack trace to the Guppy mailing list. I'd say this is a bit too specialised a problem for the general population of StackOverflow to be able to help with, but if the crash is in heapy, the developers can probably point you in the right direction.

I don't know how to tackle this problem.

The "standard" way to debug any SIGSEGV crash is to run the program (python in this case) under a debugger (GDB on Linux) and get a crash stack trace:

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

Depending on what you see in the stack trace, you may be able to make an educated guess about the root cause, or someone here might help you.

But without that info, nobody can really help you.

Update: I've built guppy-0.1.9 on Linux/x86_64 and run the commands that cause your crash (no crash for me) under Valgrind, which showed no errors.

Chances are, the problem is triggered by either the exact version on Python, the version of the compiler used to build python or guppy, or the environment. I suggest varying these (environment is probably easiest to vary) and see if you can make the problem go away and/or re-appear on another machine. If you can narrow down the conditions under which the crash shows up, your chances of getting the bug fixed will be much improved.

Failing that, get your hands dirty with debugging C -- you are in the best position to debug the problem since you are the only one who can observe it.

as a workaround, notice the PyErr_Display in the stack trace. http://www.google.com/codesearch#-2BKs-LW4I0/trunk/python/src/Python/pythonrun.c&q=function:PyErr_Display&type=cs&l=1186

Could there be some error happening? If the segfault is a coding error in one of the softwares, perhaps if you get rid of the python exception, you are free. Id suggest to try to find out what exception is happening, with gdb (or ddd)

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.