On Thu, May 19, 2011 at 11:16 AM, Christian Marquardt <marquardt.christ...@gmail.com> wrote: > 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?
Exactly! :) My os.popen test case was created because my application fails - the app uses ctypes - ctypes uses os.popen to determine system and libraries available While the os.popen does not cause my app to crash with UCS4, still my application segfaults... just in different place. I will try to narrow it and provide some stack trace later this evening. Best regards, Artur > 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 > > ------------------------------------------------------------------------------ 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
