[Pkg-exppsy-maintainers] Segfault example

Yaroslav Halchenko debian at onerussian.com
Wed Jan 16 22:06:27 UTC 2008


What I meant is smth like

$> uname -a
Linux belka 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686
GNU/Linux

*$> dpkg -l python-numpy atlas3-base python2.4  libc6
ii  atlas3-base    3.6.0-20.6     Automatically Tuned Linear Algebra Software,
ii  libc6          2.7-2          GNU C Library: Shared libraries
ii  python-numpy   1:1.0.3-1      Numerical Python adds a fast array facility 
ii  python2.4      2.4.4-5        An interactive high-level object-oriented la

I will check it on amd64 box too...

On Wed, 16 Jan 2008, Per B. Sederberg wrote:

> Veeerrry interesting!

> I, too, ran on a i386 machine, but Michael's was running amd64.  My
> numpy version is:

> $ python2.4
> Python 2.4.4 (#2, Jan  3 2008, 13:36:28)
> [GCC 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy
> >>> numpy.version.version
> '1.0.4'


> Thanks for trying it out.  I have yet to find anything on the web
> about this, but will let you know if I do.

> Thanks,
> Per


> On Jan 16, 2008 4:54 PM, Yaroslav Halchenko <debian at onerussian.com> wrote:
> > Sorry I didn't follow up -- I did run and reproduced -- it puked many times and
> > at the end with (which is I think what you got also). I was going to debug it a
> > bit more but yet had a chance... will do later...  From Michael we should get
> > versions of involved packages (numpy, blas, lapack) to see what makes the
> > difference... Also - I ran it on i386 box...  what did you run it on?

> > ==10429== Invalid read of size 4
> > ==10429==    at 0x503DD6D: ATL_dcopy_xp1yp1aXbX (in /usr/lib/atlas/libblas.so.3.0)
> > ==10429==  Address 0x5A8B5A0 is 8 bytes after a block of size 880,000 alloc'd
> > ==10429==    at 0x40244B0: malloc (vg_replace_malloc.c:149)
> > ==10429==    by 0x470FCA0: (within /usr/lib/python2.4/site-packages/numpy/core/multiarray.so)
> > ==10429==    by 0x4711EF3: (within /usr/lib/python2.4/site-packages/numpy/core/multiarray.so)
> > ==10429==    by 0x4712071: (within /usr/lib/python2.4/site-packages/numpy/core/multiarray.so)
> > ==10429==    by 0x80B9C49: PyEval_EvalFrame (in /usr/bin/python2.4)
> > ==10429==    by 0x80BB0E4: PyEval_EvalCodeEx (in /usr/bin/python2.4)
> > ==10429==    by 0x80B9319: PyEval_EvalFrame (in /usr/bin/python2.4)
> > ==10429==    by 0x80B99C3: PyEval_EvalFrame (in /usr/bin/python2.4)
> > ==10429==    by 0x80B99C3: PyEval_EvalFrame (in /usr/bin/python2.4)
> > ==10429==    by 0x80BB0E4: PyEval_EvalCodeEx (in /usr/bin/python2.4)
> > ==10429==    by 0x80BB156: PyEval_EvalCode (in /usr/bin/python2.4)
> > ==10429==    by 0x80DDF79: PyRun_FileExFlags (in /usr/bin/python2.4)
> > --10429-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
> > --10429-- si_code=1;  Faulting address: 0x4;  sp: 0x6250EDBC

> > valgrind: the 'impossible' happened:
> >    Killed by fatal signal
> > ==10429==    at 0x3801FFEA: unlinkBlock (m_mallocfree.c:314)
> > ==10429==    by 0x380208A0: vgPlain_arena_free (m_mallocfree.c:1162)
> > ==10429==    by 0x38036501: vgPlain_cli_free (replacemalloc_core.c:108)
> > ==10429==    by 0x38001A1B: die_and_free_mem (mc_malloc_wrappers.c:111)
> > ==10429==    by 0x38036C82: do_client_request (scheduler.c:1158)
> > ==10429==    by 0x380385A0: vgPlain_scheduler (scheduler.c:869)
> > ==10429==    by 0x38058946: run_a_thread_NORETURN (syswrap-linux.c:87)

> > sched status:
> >   running_tid=1

> > Thread 1: status = VgTs_Runnable
> > ==10429==    at 0x40240CA: free (vg_replace_malloc.c:233)
> > ==10429==    by 0x505495E: ATL_dmmJIK (in /usr/lib/atlas/libblas.so.3.0)




> > On Wed, 16 Jan 2008, Per B. Sederberg wrote:

> > > Hi Yarik:

> > > Did you have the chance to run the ridge regression example code that
> > > is breaking on my machine?  Michael ran it on his machine and could
> > > not reproduce the error.

> > > This is getting quite weird and I'm not sure where to go from here.
> > > It breaks at the same point (returning from the _train call) for all
> > > of my actual data.  The call to the numpy.linalg.lstsqr runs with no
> > > error and returns the correct values while inside the _train call, but
> > > all goes haywire upon the return from that method when the python
> > > garbage collection kicks in.

> > > Any thoughts on how to proceed are more than welcome from all.

> > > Thanks,
> > > Per


> > --
> > Yaroslav Halchenko
> > Research Assistant, Psychology Department, Rutgers-Newark
> > Student  Ph.D. @ CS Dept. NJIT
> > Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
> >         101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
> > WWW:     http://www.linkedin.com/in/yarik

> > _______________________________________________
> > Pkg-exppsy-maintainers mailing list
> > Pkg-exppsy-maintainers at lists.alioth.debian.org
> > http://lists.alioth.debian.org/mailman/listinfo/pkg-exppsy-maintainers



-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik        



More information about the Pkg-exppsy-maintainers mailing list