Re: [f2py] segmentation fault

Hi again

this example was to explain my question

actutally to reproduce the crash, i need to fill the memory, so the
example is nor simple nor didactical. I'll try it

and thanks for the gdb user's guide. I didn't figure out how to access
the debug info
in the gdg statement the only notable thing is:
[New Thread 0x41e24950 (LWP 10057)]
then the module runs
then crashes
and then
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f6de46396e0 (LWP 10053)]
0x00007f6de38b03c4 in strncpy () from /lib/libc.so.6

and I was not talking about the order of the variables in python, but
in fortran.  Like I had some problems untilI used the old convention
in fortran writing the subroutine itself, like
subroutine(integers, arrays)

thanks
Xavier
If the new version of f2py does not change anything, I'll try to make
a minimalist crashing example, but I am not sure it will be so
minimalist nor you would like to debug the code. thanks again

2010/11/2 Pearu Peterson <[email protected]>:
> 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
>
> _______________________________________________
> f2py-users mailing list
> f2py-users-Y4l6ocDipWCuvFJfX82//[email protected]
> http://cens.ioc.ee/mailman/listinfo/f2py-users
>