[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#684214: marked as done (gcc-4.7: Fail to build functional python/numpy extension)

Your message dated Mon, 10 Sep 2012 16:25:22 +0200
with message-id <504DF852.9050106@debian.org>
and subject line Re: Bug#684214: gcc-4.7: Fail to build functional python/numpy extension
has caused the Debian Bug report #684214,
regarding gcc-4.7: Fail to build functional python/numpy extension
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
684214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684214
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: gcc-4.7
Version: 4.7.1-6
Severity: normal


When building a C extension to Python that uses Numpy (more precisely that tries
to access a Numpy array from C), the resulting module segfaults when used. I
spent some time figuring out what was the origin of the problem (similar extension
I wrote did work in the past), and the problem is solved when compiling the 
module with olde gcc version (both gcc-4.5 and gcc-4.6 did build functional modules,
I couldn't install older version of gcc-4.7 for further testing), so I assume there 
is a problem with this version for compiling numpy modules.

Here is an minimal example, I hope it can reproduce the bug (and that the fault is 
not from my code, sorry if it is the case...). It works correctly when compiled 
with gcc-4.[56], and segfaults when compiled with gcc-4.7. It can be compiled by:
gcc-4.[5-7] -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c essai.c -o essai.o -march=native -g0
gcc-4.[5-7] -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro essai.o -o essai.so
(the compile options are as automatically generated by distutils stuff).

For testing it, you can simply do on a python shell:
>>> from essai import func
>>> import numpy as N
>>> x = N.zeros((10,10))+1.
>>> func(x,4)
It should return 25.25. It segfaults during the PyArray_ContiguousFromObject call (when 
getting access to the numpy array from C).

Here is the code:
#include <Python.h>
#include <stdio.h>
#include <numpy/arrayobject.h>

static char func_doc[] = "func(data, val)\n";

static PyObject* func(PyObject *self, PyObject *args)
{
    PyObject *input;
    PyArrayObject *data;
    double res=1.;
    int val;
    int i,j;

    if (!PyArg_ParseTuple(args, "Ol", &input, &val)) return NULL;
    data = (PyArrayObject *) PyArray_ContiguousFromObject(input, PyArray_DOUBLE, 2, 2);
    if (data == NULL) return NULL;

    for (i = 0; i < (int) data->dimensions[0]; ++i)
    	for (j = 0; j < (int) data->dimensions[1]; ++j)
	    res += ((double *)data->data)[i + j*data->dimensions[0]];

    res /= val;
    return Py_BuildValue("d", res);
}

static PyMethodDef module_methods[] = {
    {"func", func, METH_VARARGS, func_doc},
    {NULL, NULL, 0, NULL}
};

PyMODINIT_FUNC initessai(void)
{
    Py_InitModule("essai", module_methods);
    import_array();
}




-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.4-trunk-amd64 (SMP w/24 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages gcc-4.7 depends on:
ii  binutils      2.22-7.1
ii  cpp-4.7       4.7.1-6
ii  gcc-4.7-base  4.7.1-6
ii  libc6         2.13-35
ii  libgcc1       1:4.7.1-6
ii  libgmp10      2:5.0.5+dfsg-2
ii  libgomp1      4.7.1-6
ii  libitm1       4.7.1-6
ii  libmpc2       0.9-4
ii  libmpfr4      3.1.0-5
ii  libquadmath0  4.7.1-6
ii  zlib1g        1:1.2.7.dfsg-13

Versions of packages gcc-4.7 recommends:
ii  libc6-dev  2.13-35

Versions of packages gcc-4.7 suggests:
pn  binutils-gold        <none>
pn  gcc-4.7-doc          <none>
pn  gcc-4.7-locales      <none>
ii  gcc-4.7-multilib     4.7.1-6
pn  libgcc1-dbg          <none>
pn  libgomp1-dbg         <none>
pn  libitm1-dbg          <none>
pn  libmudflap0-4.7-dev  <none>
pn  libmudflap0-dbg      <none>
pn  libquadmath0-dbg     <none>

-- no debconf information

--- End Message ---
--- Begin Message --- 
On 07.08.2012 23:04, Raphael Plasson wrote:
> static PyObject* func(PyObject *self, PyObject *args)
> {
>     PyObject *input;
>     PyArrayObject *data;
>     double res=1.;
>     int val;
>     int i,j;
> 
>     if (!PyArg_ParseTuple(args, "Ol", &input, &val)) return NULL;

your code is wrong. you pass an int, but parse a long.

--- End Message ---
Reply to: