Ubuntu has a much shorter cycle of updates than Fedora, indeed.

On 03/10/2010 06:27 AM, Charles R Harris wrote:


On Tue, Mar 9, 2010 at 5:52 PM, Johann Cohen-Tanugi <co...@lpta.in2p3.fr <mailto:co...@lpta.in2p3.fr>> wrote:

    more fun :
    [co...@jarrett tests]$ pwd
    /home/cohen/sources/python/numpy/numpy/core/tests
    [co...@jarrett tests]$ python -c 'import test_ufunc'

    python: Modules/gcmodule.c:277: visit_decref: Assertion
    `gc->gc.gc_refs != 0' failed.
    Aborted (core dumped)

    and in the debugger:
    (gdb) run
    Starting program: /usr/bin/python
    warning: .dynamic section for "/lib/libpthread.so.0" is not at the
    expected address

    warning: difference appears to be caused by prelink, adjusting
    expectations
    warning: .dynamic section for "/lib/libdl.so.2" is not at the
    expected address

    warning: difference appears to be caused by prelink, adjusting
    expectations
    warning: .dynamic section for "/lib/libc.so.6" is not at the
    expected address

    warning: difference appears to be caused by prelink, adjusting
    expectations
    [Thread debugging using libthread_db enabled]

    Python 2.6.2 (r262:71600, Jan 25 2010, 18:46:45)
    [GCC 4.4.2 20091222 (Red Hat 4.4.2-20)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import test_ufunc

    >>>
    >>>
    python: Modules/gcmodule.c:277: visit_decref: Assertion
    `gc->gc.gc_refs != 0' failed.

    Program received signal SIGABRT, Aborted.
    0x00aab416 in __kernel_vsyscall ()
    Missing separate debuginfos, use: debuginfo-install
    atlas-3.8.3-12.fc12.i686 libgcc-4.4.3-4.fc12.i686
    libgfortran-4.4.3-4.fc12.i686
    (gdb) bt
    #0  0x00aab416 in __kernel_vsyscall ()
    #1  0x00159a91 in raise (sig=6) at
    ../nptl/sysdeps/unix/sysv/linux/raise.c:64
    #2  0x0015b35a in abort () at abort.c:92
    #3  0x00152be8 in __assert_fail (assertion=<value optimized out>,
    file=<value optimized out>, line=<value optimized out>,
    function=<value optimized out>) at assert.c:81
    #4  0x0050931e in visit_decref (op=<value optimized out>,
    data=<value optimized out>) at Modules/gcmodule.c:277
    #5  0x0047c8c2 in dict_traverse (op=<value optimized out>,
    visit=<value optimized out>, arg=<value optimized out>) at
    Objects/dictobject.c:2003
    #6  0x00509af3 in subtract_refs (generation=<value optimized out>)
    at Modules/gcmodule.c:296

    #7  collect (generation=<value optimized out>) at
    Modules/gcmodule.c:817
    #8  0x0050a640 in PyGC_Collect () at Modules/gcmodule.c:1292
    #9  0x004fb0f0 in Py_Finalize () at Python/pythonrun.c:424
    #10 0x0050868f in Py_Main (argc=<value optimized out>, argv=<value
    optimized out>) at Modules/main.c:625
    #11 0x080485c8 in main (argc=<value optimized out>, argv=<value
    optimized out>) at Modules/python.c:23

    which looks identical to the bt I sent to Robert earlier on.

    HTH,
    Johann


    On 03/10/2010 12:43 AM, Johann Cohen-Tanugi wrote:


    On 03/10/2010 12:33 AM, Johann Cohen-Tanugi wrote:


    On 03/10/2010 12:07 AM, Pauli Virtanen wrote:
    ti, 2010-03-09 kello 21:14 +0100, Johann Cohen-Tanugi kirjoitti:
    thinking about it, this morning there was a fedora update to python, so
    I am using 2.6.2-4.fc12.
    Looks like the problem is in python itself, hence this piece of info.
    That the problem would be in Python is not so clear to me. Can you try
    running it with the previous Python shipped by Fedora? Do you see the
    problem then? What's the previous version, btw?
    2.6.2-1 IIRC. I would have to check, and I am not sure how to
    either query this information or step back one update up with yum :(
    Memory errors are somewhat difficult to debug. Can you try running only
    a certain subset of the tests, first

        nosetests numpy.core
    crash
    Be sure to set Pythonpath so that you get the correct Numpy version. If
    it segfaults, proceed to (under numpy/core/tests)

        nosetests test_multiarray.py
        nosetests test_multiarray.py:TestNewBufferProtocol
    neither crash, so the problem is not there....
    I followed your lead and tried each script and ended up with :
    [co...@jarrett tests]$ nosetests test_ufunc.py
    .............
    ----------------------------------------------------------------------
    Ran 13 tests in 1.146s

    OK
    python: Modules/gcmodule.c:277: visit_decref: Assertion
    `gc->gc.gc_refs != 0' failed.
    Aborted (core dumped)

    so test_ufunc.py seems to be at stake

    Since the crash occurs in cyclic garbage collection, I'm doubting a bit
    the numpy/core/src/multiarray/numpymemoryview.c implementation, since
    that's the only part in Numpy that supports that.

    Alternatively, just replace numpymemoryview.c with the attached one
    which has cyclic GC stripped, and see if you still get the crash.

    Cheers,
    Pauli



    _______________________________________________
    NumPy-Discussion mailing list
    NumPy-Discussion@scipy.org  <mailto:NumPy-Discussion@scipy.org>
    http://mail.scipy.org/mailman/listinfo/numpy-discussion

-- This message has been scanned for viruses and
    dangerous content by *MailScanner*
    <http://www.mailscanner.info/>, and is
    believed to be clean.


    _______________________________________________
    NumPy-Discussion mailing list
    NumPy-Discussion@scipy.org  <mailto:NumPy-Discussion@scipy.org>
    http://mail.scipy.org/mailman/listinfo/numpy-discussion


Python 2.6.2 is rather old by now, the bugfix releases are up to 2.6.4. I don't know that that is related, but I haven't seen any crashes on ubuntu with 2.6.4.

Chuck

--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.


_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Reply via email to