Hmm,
I've been building our python (2.7.1) with --enable-unicode=ucs4 which I
believe stands for 4-byte Unicode. In any case, Rpy handles (should handle?)
the Unicode conversion through python C-API calls which should behave
consistently with the way the original python has been build.
As I said before, our python is not build with FCC, but with Intel's C/C++
compilers, and I can't reproduce the popen() segmentation fault, but get one at
a different place. So I agree with Artur: what is the real reason of the seg
fault(s) that come up for various people on various platforms with various
compilers?
Chris.
On 19 May 2011, at 11:22, Thomas Kluyver <tak...@gmail.com> wrote:
> On 19 May 2011 08:19, Artur Wroblewski <wrob...@pld-linux.org> wrote:
> On Thu, May 19, 2011 at 12:19 AM, Thomas Kluyver <tak...@gmail.com> wrote:
> > Ah, Unicode. I believe the builds from python.org are narrow unicode (i.e.
> > UTF-16), whereas those shipped in many Linux distros (including the one I
> > use) are wide unicode (UTF-32). This might explain why I can't replicate
> > your segfaults.
>
> The question is what is the real reason of segv. :)
>
> At a guess: if C code in rpy2 is somehow assuming that PyUnicode objects are
> stored as 4-bytes per character, then when it tries to access one that's
> stored as only 2 bytes per character, it would try to use a block of memory
> twice the size of the object, which may take it outside the memory it owns
> (i.e. a segfault).
>
> Why that would be happening on import, or interacting with os.popen, I don't
> know. But if we can only trigger the segfaults on narrow unicode Python
> builds, we've got a place to start looking, at least.
>
> Anyone else who's tried to replicate this: can you get a segfault, and is
> your Python wide- or narrow-unicode? If you're not sure about the latter,
> check sys.maxunicode - it should be 65535 for narrow, or 1114111 for wide.
>
> Thomas
> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including 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
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including 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
