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