On 06/04/11 09:14, Christian Marquardt wrote:
> Laurent,
>
> the problem occurs with 2.2.0-alpha4 - is that not the most recent
> version / snapshot?

That's the most recent "release". The most recent snapshot might have 
further modifications.

>
> I made reference to the same problem in 2.1.9 because it suggests
> (IMHO) that whatever the problem is, it might only indirectly be
> caused by the most recent changes in rpy. So a diff might not help
> that much, in fact. Given that the problem only occurs in conjunction
> with another module and a not-so-common compiler, I wouldn't even
> claim that it is actually an rpy problem; it might be related to scipy
> or even the Intel compiler.

Yes, an unfortunate negative interaction between scipy, the Intel 
compiler, may be even Python and R is possible. In that case there is 
little one could do for you (beside trying to reproduce the issue, and I 
personally do not have a copy of the Intel compiler, and have some time 
available to run after the bug).

> Unfortunately, I do not know enough about
> CPython's and rpy's internals to immediately see which code is
> executed when.

This kind of debugging can be nasty to track. You can try building rpy2 
with verbose flags (python setup.py build_ext -DDEBUG) but I am not 
certain that it will help much. Having a debug build of Python and 
running it through gdb might be what is needed (/if/ gdb can be used 
with code compiled with the Intel compiler).

>
> What would help me to track the problem down further is some help in
> understanding which parts of the rpy code is executed when python does
> an 'exit()', for example.

garbage collection of (some of) the R object exposed to Python. I don't 
remember having a call to endr implemented (actually, that might be a 
test: try calling rpy2.rinterface.endr() before exit() ).

>
>     Christian.
>
> On Tue, Apr 5, 2011 at 9:28 PM, Laurent Gautier<lgaut...@gmail.com>  wrote:
>> On 4/5/11 10:08 PM, Christian Marquardt wrote:
>>>
>>> Hi,
>>>
>>> I reported something very similar for v2.1.9 (see
>>>
>>> http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTimOkRDv98e5ZcyzmJrzsdYq3%2B6iqAC7_FNk_p53%40mail.gmail.com&forum_name=rpy-list).
>>>
>>> With RPy 2.2.0 alpha4, python 2.7.1, numpy 1.5.1, scipy 0.8.0 and R
>>> 2.12.1, all compiled with the Intel compiler suite (11.1) including
>>> MKL, and running on Linux (OpenSuse 11.1), this happens:
>>>
>>>     TCPC2069 (rpy2-alpha4) /homespace/grasppf>python
>>>     Python 2.7.1 (r271:86832, Nov 30 2010, 12:31:54)
>>>     [GCC Intel(R) C++ gcc 4.3 mode] on linux2
>>>     Type "help", "copyright", "credits" or "license" for more information.
>>>     >>>    import numpy as np
>>>     >>>    import scipy.interpolate
>>>     >>>    import rpy2.robjects as ro
>>>     >>>    exit()
>>>     Segmentation fault
>>>     TCPC2069 (rpy2-alpha4) /homespace/grasppf>
>>>
>>> On the other hand, when changing the order of imports,
>>>
>>>     TCPC2069 (rpy2-alpha4) /homespace/grasppf>python
>>>     Python 2.7.1 (r271:86832, Nov 30 2010, 12:31:54)
>>>     [GCC Intel(R) C++ gcc 4.3 mode] on linux2
>>>     Type "help", "copyright", "credits" or "license" for more information.
>>>     >>>    import numpy as np
>>>     >>>    import rpy2.robjects as ro
>>>     >>>    import scipy.interpolate
>>>     >>>    exit()
>>>     TCPC2069 (rpy2-alpha4) /homespace/grasppf>
>>>
>>> no segfault happens. With v2.2.0-alpha2, both variants worked fine.
>>>
>>> Does anyone have an idea where I could try starting to debug RPy's C code?
>>
>> Try "hg diff"...
>>
>> ;-)
>>
>> I can only advice to embrace ryp2-2.2.0, and eventually help make it better,
>> rather than spent valuable time on end-of-life software.
>>
>>
>>
>> L.
>>
>>
>>>
>>> Thanks,
>>>
>>>     Christian
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Xperia(TM) PLAY
>>> It's a major breakthrough. An authentic gaming
>>> smartphone on the nation's most reliable network.
>>> And it wants your games.
>>> http://p.sf.net/sfu/verizon-sfdev
>>> _______________________________________________
>>> rpy-list mailing list
>>> rpy-list@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/rpy-list
>>
>>


------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list

Reply via email to