Android provides a minimal support of locales. Most functions return a fake result, do nothing. I'm not sure that it supports any codec. To support Android, we may force UTF-8 for the filesystem encoding, as done on Mac OS X.
Victor 2015-01-30 19:04 GMT+01:00 Ryan Gonzalez <rym...@gmail.com>: > No... > > ...but I think I found the issue with grep. Try applying the attached patch > to the Python/frozenmain.c. It comments out the locale handling. > > It seems that Python always calls its strdup function on the locale string. > On Android, this can apparently be null (as seen in the bug report you > linked to). > > On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton <chasel...@gmail.com> wrote: >> >> I don't have gdb on device; does the following tell you where Python's >> strdup is called? >> >> >> _PyMem_RawStrdup >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >> >> On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez <rym...@gmail.com> wrote: >> > Is it possible at all to get a stack trace of the crash using gdb? Try >> > the >> > steps here. >> > >> > That way we can see where Python's own strdup function is getting >> > called. >> > >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton <chasel...@gmail.com> >> > wrote: >> >> >> >> Absolutely. Good thing I have addr2line on device >> >> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e /lib/libpython3.4m.so.1.0 >> >> 0008bbc8 >> >> _PyMem_RawStrdup >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >> >> /bld/python/Python-3.4.2 $ >> >> >> >> >> >> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan <rym...@gmail.com> wrote: >> >> > Could you try the steps at >> >> > http://stackoverflow.com/a/11369475/2097780? >> >> > They >> >> > allow you to get a better idea of where libc is crashing. >> >> > >> >> > Cyd Haselton <chasel...@gmail.com> wrote: >> >> >> >> >> >> Managed to get this out of logcat: >> >> >> F(11914) Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread >> >> >> 11914 (python) (libc) >> >> >> >> >> >> [ 01-29 19:30:55.855 23373:23373 F/libc ] >> >> >> Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 23373 >> >> >> (python) >> >> >> >> >> >> Less detail than strace but it seems to be that python is >> >> >> segfaulting >> >> >> libc... >> >> >> >> >> >> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez <rym...@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >>> <gu...@python.org> >> >> >>> wrote: >> >> >>>> >> >> >>>> >> >> >>>> What I see in the strace: >> >> >>>> >> >> >>>> ... load libpython3.4m.so.1.0 >> >> >>>> ... load libm >> >> >>>> ... open /dev/__properties__ and do something to it >> >> >>>> (what?) >> >> >>>> ... get current time >> >> >>>> ... allocate memory >> >> >>>> ... getuid >> >> >>>> ... segfault >> >> >>>> >> >> >>>> That's not a lot to go on, but it doesn't look as if it has >> >> >>>> started >> >> >>>> to >> >> >>>> load modules yet. >> >> >>>> >> >> >>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >>> is the code that works with that file. >> >> >>> >> >> >>> This explains it a bit (slides 24-29). Looks like something to do >> >> >>> with >> >> >>> interprocess communication. Likely has nothing to do with Python >> >> >>> itself. >> >> >>> >> >> >>> Maybe this would be useful? >> >> >>> >> >> >>>> >> >> >>>> That stack trace would be really helpful. >> >> >>>> >> >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >>>> <chasel...@gmail.com> >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>> Apologies...I'm not sure what a stack track is, but I do have >> >> >>>>> the >> >> >>>>> strace. Nearest I can tell, it happens due to an open call, >> >> >>>>> though >> >> >>>>> I >> >> >>>>> am probably wrong. >> >> >>>>> Attaching the strace output to this email. I'm going to head >> >> >>>>> back >> >> >>>>> to >> >> >>>>> the documentation and to back out of some Android-related >> >> >>>>> changes >> >> >>>>> in >> >> >>>>> _localemodule.c >> >> >>>>> >> >> >>>>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum >> >> >>>>> <gu...@python.org> >> >> >>>>> wrote: >> >> >>>>>> >> >> >>>>>> There could be a million differences relevant (unicode, ints, >> >> >>>>>> ...). >> >> >>>>>> Perhaps >> >> >>>>>> the importlib bootstrap is failing. Perhaps the dynamic loading >> >> >>>>>> code >> >> >>>>>> changed. Did you get a stack track? (IIRC strace shows a >> >> >>>>>> syscall >> >> >>>>>> trace >> >> >>>>>> -- >> >> >>>>>> also useful, but doesn't tell you precisely how >> >> >>>>>> it segfaulted.) >> >> >>>>>> >> >> >>>>>> On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton >> >> >>>>>> <chasel...@gmail.com> >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> All, >> >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android >> >> >>>>>>> in >> >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >> >>>>>>> configure >> >> >>>>>>> options in the same environment, and modifying the setup.py as >> >> >>>>>>> needed, >> >> >>>>>>> the newly built binary throws a segfault when the >> >> >>>>>>> generate-posix-vars >> >> >>>>>>> portion of the build is reached...and when it is run as well >> >> >>>>>>> (i.e. >> >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> >>>>>>> >> >> >>>>>>> I took a strace of ./python, however I'm a bit lost when >> >> >>>>>>> reviewing >> >> >>>>>>> it. >> >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >> >> >>>>>>> works >> >> >>>>>>> but >> >> >>>>>>> 3.x throws a segfault? >> >> >>>>>>> >> >> >>>>>>> Thanks in advance, >> >> >>>>>>> Cyd >> >> >>>>>>> ________________________________ >> >> >>>>>>> >> >> >>>>>>> Python-Dev mailing list >> >> >>>>>>> >> >> >>>>>>> Python-Dev@python.org >> >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>>> Unsubscribe: >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> --Guido van Rossum (python.org/~guido) >> >> >>>> >> >> >>>> ________________________________ >> >> >>>> >> >> >>>> Python-Dev mailing list >> >> >>>> Python-Dev@python.org >> >> >>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>> Unsubscribe: >> >> >>>> >> >> >>>> >> >> >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Ryan >> >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >> >>> simple: >> >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >>> that >> >> >>> was >> >> >>> nul-terminated." >> >> >>> Personal reality distortion fields are immune to contradictory >> >> >>> evidence. >> >> >>> - >> >> >>> srean >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> > >> >> > >> >> > -- >> >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> > Check out my website: http://kirbyfan64.github.io/ >> > >> > >> > >> > >> > -- >> > Ryan >> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >> > nul-terminated." >> > Personal reality distortion fields are immune to contradictory evidence. >> > - >> > srean >> > Check out my website: http://kirbyfan64.github.io/ > > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
