Re: [f2py] segmentation fault

On 11/02/2010 08:54 AM, Xavier Barthelemy wrote:
> Hi again
>
> this example was to explain my question
>
> actutally to reproduce the crash, i need to fill the memory,

hmm, I would expect crashes when computer doesn't have enough memory 
(ram+cache).

> so the example is nor simple nor didactical. I'll try it
....
> 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

My interest in debugging your code is to find bugs in f2py.
Also, a crashing example would be more effective in getting
support from the ml, I think.

Best regards,
Pearu

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