[SciPy-dev] f2py and ATLAS crashing bug

[Charles R Harris]

On Sun, Nov 8, 2009 at 6:46 PM, Anne Archibald <peridot.faceted at gmail.com>wrote:

> 2009/11/8 Charles R Harris <charlesr.harris at gmail.com>:
> >
> > On Sun, Nov 8, 2009 at 4:42 PM, Anne Archibald <
> aarchiba at physics.mcgill.ca>
> > wrote:
> >>
> >> Hi,
> >>
> >> I am still trying to fix the bug where non-aligned matrices can cause
> >> ATLAS to segfault, and I think I need to improve my understanding of
> >> f2py somewhat.
> >>
> >> First of all, I'll note that the bug appears in several routines (eig,
> >> svd, qr, rq, hessenberg, and schur that I have found so far) but only
> >> when the overwrite_a flag is passed in. So I tried to determine how
> >> overwrite_a is used in these routines, and I am puzzled. The python
> >> routines appear to pass it unmodified to the FORTRAN routines. The
> >> .pyf files mention it in the python call signatures, but nowhere else;
> >> from the f2py files it looks like it should be ignored. But clearly it
> >> has some effect, since it allows crashes.
> >>
> >
> > I'm going to guess there is a conflict between the overwrite flag and the
> > copy flag. Might be considered a bug, but I'm not sure how those two
> should
> > interact anyway. The quick fix would seem to be to not use overwrite,
> which
> > might have the same effect you are shooting for with the copy flag. Pearu
> > probably needs to take a look at the flag interaction and maybe we can
> maybe
> > fix things differently at some point. Does everything work if you just
> don't
> > set the overwrite flag?
>
> The two flags are at very different levels: the copy flag is set in
> the f2py spec file, as a property of the underlying C/Fortran routine,
> while overwrite_a is a python-level parameter that can (unfortunately)
> be set by the user.
>
> In principle, overwrite_a is specified by the user to say that they
> don't mind if the routine uses the input matrix as scratch space. In
> an ideal world, this would automatically get set when the python
> wrappers need to copy the matrix, since the user doesn't even have
> access to the matrix that actually gets passed in to the underlying
> routine.
>
> I have to say I don't understand the f2py flags well enough to know
> whether the fact that the underlying routine modifies the input matrix
> means that the f2py spec file should contain intent(out).
>

I think the intent(out) only means that the array will be returned to the
user. I would also expect that the overwrite isn't so much providing scratch
space as saying that the routine can do it's work inplace, so in that
situation the array should probably be marked for both input and output. But
I think Pearu need to be consulted here because things don't seem to be
working right.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091108/0177b406/attachment.html>