Is it possible at all to get a stack trace of the crash using gdb? Try the steps here <http://stackoverflow.com/a/10539883/2097780>.
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/
_______________________________________________ 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
