On 4/12/10 9:31 PM, Yaroslav Halchenko wrote:
> I am still experiencing problems (segfault) in pymvpa with rpy2 on 64bit.
That's annoying. Let's see what we can do about it.
> But
> lets start with unittests -- if I try using nosetests to discover/run them
> then
> I can get a segfault too:
>
> 1. probably R issue, not RPy2 -- but wanted to check with you:
>
> ,---
> | $> MVPA_SEED=1
> PYTHONPATH=/home/yoh/proj/rpy2/build/lib.linux-x86_64-2.6:$PWD
> /usr/bin/python2.6 /usr/bin/nosetests -s -v rpy2
> | ...
> | TypeError: clip() takes exactly 1 argument (5 given)
> | NotImplementedError: Device mode not implemented.
> | ok
> | testSize (rpy2.rinterface.tests.test_Device.ConcreteDeviceTestCase) ...
> done.
> | ERROR
> | testChooseFileWithError
> (rpy2.rinterface.tests.test_EmbeddedR.CallbacksTestCase) ... Error in
> function (new = FALSE) : file choice cancelled
> | zsh: segmentation fault MVPA_SEED=1
> PYTHONPATH=/home/yoh/proj/rpy2/build/lib.linux-x86_64-2.6:$PWD
> `---
>
> so segfault again but probably is different from ours in pymvpa (yet to
> provide details): while running via nosetests R complaints a lot "Device mode
> not implemented",
I am not familiar with "nosetests" so I can't have a clear idea of what
is happening.
Device-related tests should be turned off by default. Can you details
your installation process ? Did you make sure that you wiped out any
earlier version ?
> and then segfault seems to fit the "bill":
Can anyone else reproduce this ?
> NotImplementedError: Device deactivation not implemented.
> NotImplementedError: Device activation not implemented.
> done.
> ok
> testCanGenKeybd (rpy2.rinterface.tests.test_Device.AbstractDeviceTestCase)
> ... ==26349== Invalid read of size 8
> ==26349== at 0x9293B84: GEaddDevice (devices.c:451)
> ==26349== by 0x9293C0D: GEaddDevice2 (devices.c:501)
> ==26349== by 0xFF8993A: GrDev_init (rpy_device.c:1252)
> ==26349== by 0x484EF3: type_call (typeobject.c:742)
> ==26349== by 0x425FE4: PyObject_Call (abstract.c:2492)
> ==26349== by 0x4D1692: do_call (ceval.c:3946)
> ==26349== by 0x4D0A10: call_function (ceval.c:3751)
> ==26349== by 0x4CB91E: PyEval_EvalFrameEx (ceval.c:2411)
> ==26349== by 0x4D0D0D: fast_function (ceval.c:3814)
> ==26349== by 0x4D09EE: call_function (ceval.c:3749)
> ==26349== by 0x4CB91E: PyEval_EvalFrameEx (ceval.c:2411)
> ==26349== by 0x4CE0C5: PyEval_EvalCodeEx (ceval.c:2990)
> ==26349== Address 0xcb1f750 is 256 bytes inside a block of size 488 free'd
> ==26349== at 0x4C21DBC: free (vg_replace_malloc.c:325)
> ==26349== by 0x4649EB: PyObject_Free (obmalloc.c:1125)
> ==26349== by 0x464E27: _PyObject_DebugFree (obmalloc.c:1381)
> ==26349== by 0x46360C: PyMem_Free (object.c:2287)
> ==26349== by 0xFF88B9B: GrDev_dealloc (rpy_device.c:705)
> ==26349== by 0x4632F2: _Py_Dealloc (object.c:2198)
> ==26349== by 0x59C2F0: frame_dealloc (frameobject.c:420)
> ==26349== by 0x4632F2: _Py_Dealloc (object.c:2198)
> ==26349== by 0x4D0D7E: fast_function (ceval.c:3816)
> ==26349== by 0x4D09EE: call_function (ceval.c:3749)
> ==26349== by 0x4CB91E: PyEval_EvalFrameEx (ceval.c:2411)
> ==26349== by 0x4D0D0D: fast_function (ceval.c:3814)
>
>
> (gdb) p oldd
> $2 = (pGEDevDesc) 0xcb1f660
> *(gdb) p *oldd
> $3 = {dev = 0xdbdbdbdbdbdbdbdb, displayListOn = 3688618971, displayList =
> 0xdbdbdbdbdbdbdbdb, DLlastElt = 0xdbdbdbdbdbdbdbdb, savedSnapshot =
> 0xdbdbdbdbdbdbdbdb, dirty = 3688618971, recordGraphics = 3688618971, gesd =
> {0xdbdbdbdbdbdbdbdb<repeats 24 times>}, ask = 3688618971}
> *(gdb) p *oldd->dev
> Cannot access memory at address 0xdbdbdbdbdbdbdbdb
>
> and that happens in
> /home/yoh/proj/rpy2/build-dbg/lib/python2.6/site-packages/rpy2/rinterface/tests/test_Device.py
> (11): setUp
>
> self.gd = rdevice.GraphicalDevice()
>
> so -- it accesses the address in 'freed' space, and probably it isn't the RPy2
> issue, right?
May be it is, but with features that should no be tested or exposed. I
have concerns about your install.
> 2. minor (probably safe but would be great to have it cleaner)
> ,---
> | $> MVPA_SEED=1
> PYTHONPATH=/home/yoh/proj/rpy2/build/lib.linux-x86_64-2.6:$PWD
> /usr/bin/python2.6 /usr/bin/nosetests -s -v
> rpy2.rinterface.tests.test_EmbeddedR
> | testChooseFileWithError
> (rpy2.rinterface.tests.test_EmbeddedR.CallbacksTestCase) ... Error in
> function (new = FALSE) : file choice cancelled
> | ok
> | ...
> | testInterruptR (rpy2.rinterface.tests.test_EmbeddedR.EmbeddedRTestCase) ...
> Traceback (most recent call last):
> | File "/home/yoh/.tmp/tmp5rdj4w.py", line 1, in<module>
> | import rpy2.robjects as ro
> | File
> "/home/yoh/proj/rpy2/build/lib.linux-x86_64-2.6/rpy2/robjects/__init__.py",
> line 20, in<module>
> | from rpy2.robjects.methods import RS4
> | File
> "/home/yoh/proj/rpy2/build/lib.linux-x86_64-2.6/rpy2/robjects/methods.py",
> line 9, in<module>
> | quiet = rinterface.BoolSexpVector((True, )))
> | ValueError: The first parameter must be a tuple.
> | ok
> | testSet_initoptions
> (rpy2.rinterface.tests.test_EmbeddedR.EmbeddedRTestCase) ... ok
> | testStr_typeint (rpy2.rinterface.tests.test_EmbeddedR.EmbeddedRTestCase)
> ... ok
> | ...
> `---
>
> although tests reported to pass -- so not sure if that spit out traceback is a
> 'feature' or just somehow missed? (it is also "visible" with using python2.6
> -m
> rpy2.tests to run the tests)
>
Yes, that's annoying and a temporary feature until I spend time on how
to deal with this better.
I think that it comes from printing warnings:
http://bitbucket.org/lgautier/rpy2/src/tip/rpy/rinterface/rinterface.c#cl-1416
>
>
> On Sun, 11 Apr 2010, Laurent wrote:
>
>> I have a rather limited set of complains, so I am thinking that this is
>> somehow ready for a release.
>
>> I will have a last check at things, but better if I am not the only one
>> looking at it.
>> Please report:
>> - bugs
>> - missing features (advertised in the documentation, or that should
>> implicitly be present)
>
>> note: no win32/win64 support at this time, unless I a contributor steps
>> forward.
>
>> Thanks,
>
>
>> Laurent
>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> rpy-list mailing list
>> rpy-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/rpy-list
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
