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
