Re: [f2py] segmentation fault

Hi,

I am not able to reproduce crashes with the following code:

subroutine toto(n1,n2,toto1)

implicit none
integer*4 :: n1,n2,n3
real*8 :: toto1(n1,n2)
real*8, allocatable :: toto2(:,:)
!f2py integer(4) intend(in),depend(toto1)::n1
!f2py integer(4) intend(in),depend(toto1)::n2
!f2py real(8) dimension(n1,n2) intent(in) :: toto1
!f2py n1=shape(toto1,0)
!f2py n2=shape(toto1,1)

n3= 3
allocate(toto2(n1,n3))

return
end subroutine toto

Can you give a "working" example that crashes?

Few additional notes: since toto2 is not in the argument list, f2py does not use
any information of it, so, do not use it within f2py directives.
Also, the toto allocates toto2, but does it also deallocates it?


On Mon, Nov 1, 2010 at 3:41 AM, Xavier Barthelemy <[email protected]> wrote:
...
> the code does a seg fault after a few iteration, that means I am
> reading/writing outside of where i am supposed to do so.
>
> my fortran variable declaration is okey
> my f2py statement is ok
>
> I run f2py with these options:
> --debug-capi -DF2PY_REPORT_ATEXIT -DF2PY_REPORT_ON_ARRAY_COPY=1
> -DDEBUG_COPY_ND_ARRAY
> and the fortran compiler with every debug options -check all -debug
> all -diag-enable -C -warn
>
> all the debug and check_and_fix are ok when I call the subroutine from python
> the arrays in python are created fortran ordered.
>
> and i still have a seg fault and it's not about accessing a bad array
> index in the fortran code
>
> so my question is how can i debug this type of errors?
> sometimes, when it runs but segfault on the return from fortran to
> python I have a bad pointer allocation message with a memroy address.
> How can i use that? how can i have access to the name of what it is
> pointing?

You can use tools like ddd or gdb to find the location of segfaults.
For example,
run

ulimit -c unlimited # this will ensure that core file will be created
on segfault
python test.py # crash should create core to cwd.
gdb python core
(gdb) run test.py

> I have to say that wrinting/commenting some lines to find out where it
> stops change the place of crash in the code.
>
> What can be my tools to find out what is happening?
>
> something came to my mind too. do i have to do a f2py statement for a
> local fortran variable which the size depends on a entering parameter?
> I'll explain
>
> subroutine toto(n1,n2,toto1)
>
> implicit none
> integer*4 :: n1,n2,n3
> real*8 :: toto1(n1,n2)
> real*8, allocatable :: toto2(:,:)
> !f2py integer(4) intend(in),depend(toto1)::n1
> !f2py integer(4) intend(in),depend(toto1)::n2
> !f2py real(8) dimension(n1,n2) intent(in) :: toto1
> !f2py n1=shape(toto1,0)
> !f2py n2=shape(toto1,1)
>
> n3= blah
> allocate(toto2(n1,n3))
>
> blahblah
> return
>  end
>
> and in python i have
> toto1=numpy.empty([n1,n2], dtype='d',order='FORTRAN')
>
> and i call module.toto(n1,n2,toto1)
>
> So should I replace the 1st f2py line by
> !f2py integer(4) intend(in),depend(toto1,toto2)::n1
> and add
> !f2py n1=shape(toto2,0)

No, the n1=shape(toto2,0) would be evaluated before calling toto, so
it would not work.

> by the way I experimentally figured out that the old fortran
> convention to order the variables in calling a subroutine has
> sometimes an influence on having some wrapping errors or not
> like subroutine toto( integer first, then arrays)

f2py may change the signatures of Fortran functions when seen from
Python side. So, always check the __doc__ of generated wrappers.
More details can be found in the f2py paper.

HTH,
Pearu