I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes when
calling strlen. It's that whatever is calling it is likely asking it to
duplicate a null pointer. Basically, it's probably the caller's fault.
You could always try modifying _PyMem_RawStrdup to return NULL when given a
null pointer and see where it then segfaults.
On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton
Alternatively, is there a hassle-free way to find out what changed in obmalloc.c between 2.7.x and 3.4.x?
There's a related strdup patch for readline.c, mentioned here:http://bugs.python.org/issue21390 and here https://github.com/rave-engine/python3-android/issues/2. There's a patch, but I'm not sure how to modify it for obmalloc.c, as (I think) the functions all belong to Python...they're all prefixed with _PyXx
On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton
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
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
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
wrote:
On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum <
guido@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/prope...
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
> 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,
>> 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 < guido@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 < chaselton@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
On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton
wrote: though I 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/