Hello,

I experienced seg faults and core dumps related to rpy with several
recent versions of rpy, and reported some of them on this list. Here's
another one, this time with rpy 2.2.0beta3 (and python 2.7.1)
occurring during one of the tests coming with the source code. After
unpacking,

   cd rpy2-2.2.0beta3/rpy/rinterface/tests
   python test_SexpVector.py

gives

   testAssignItemComplex (__main__.SexpVectorTestCase) ... ok
   testAssignItemDifferentType (__main__.SexpVectorTestCase) ... ok

      [...several more tests that pass ok...]

   testNACharacterInVector (__main__.NAValuesTestCase) ... ok
   testNACharacterRepr (__main__.NAValuesTestCase) ... ok
   testNACharactertoR (__main__.NAValuesTestCase) ... ok
   testNAIntegerBinaryfunc (__main__.NAValuesTestCase) ... Segmentation fault

in my setup which is admittedly somewhat special (Intel 11.1 compilers
used for compiling python and all modules, for example, on an OpenSuse
11.1 Linux).

I have played with that particular test script; when replacing the
test suite setup at the end of the test script with

   def suite():
    suite = unittest.TestLoader().loadTestsFromTestCase(ByteSexpVectorTestCase)
    return suite

I get another odd behaviour:

   >python test_SexpVector.py

   testInitFromBytes (__main__.ByteSexpVectorTestCase) ... ok
   testInitFromSeqInvalidByte (__main__.ByteSexpVectorTestCase) ... ok
   testInitFromSeqOfBytes (__main__.ByteSexpVectorTestCase) ... ok

   ----------------------------------------------------------------------
   Ran 3 tests in 0.002s

   OK
   Segmentation fault

i.e. a seg fault upon exit (something I had seen before in a different
context; see 
http://sourceforge.net/mailarchive/forum.php?thread_name=4D9CDE71.1070705%40gmail.com&forum_name=rpy-list).
Before switching to 2.2.0beta3, we had been using 2.2.0alpha2 without
producing core dumps;but when updating to a newer version of netcdf
and Jeff Whitaker's the netCDF4 module, a rather large application of
ours suddenly started to produce segmentation faults in the middle of
nowhere (meaning that the crash occurred reproducibly in the middle of
some calculation entirely unrelated to rpy; the program just had the
rpy module loaded). Removing the import of rpy modules made it working
as before. When importing rpy2.2.0beta3 it core dumps at the same
place, but runs absolutely fine if rpy2.robjects is not imported.

Going through the mailing list archive and the bug tracker, I see that
there are different reports of similar (= segmentation fault) behavior
on different platforms which are all very difficult to reproduce, but
still bother people. Is there a way to debug rpy2 to get an idea what
might go wrong during import and shortly thereafter to track this
down? From my experience I would not be surprised if the above
behavior cannot be easily reproduced by others - and yet rpy2 seems to
produce crashes for quite some people.

Sorry - my intention is not to complain. I just feel terribly
frustrated that I cannot even provide the slightest idea where that
problem comes from, and even less how to drill it down further.

   Christian.

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list

Reply via email to