No, it returns NULL if malloc gives it a raw pointer. It unconditionally
checks the length of the (possibly null) string argument first.
Please try the patch I attached in the last email. It *might* fix the
issue. Android has crappy locale handling.
On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton
Unless i'm reading something incorrectly, _PyMem_RawStrdup is currently returning NULL when given a null pointer.
From obmalloc.c
_PyMem_RawStrdup(const char *str) { size_t size; char *copy; size = strlen(str) + 1; copy = PyMem_RawMalloc(size); if (copy == NULL) return NULL; memcpy(copy, str, size); return copy; }
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
wrote: Alternatively, is there a hassle-free way to find out what changed in obmalloc.c between 2.7.x and 3.4.x?
On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton
wrote:
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 >> >> 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 >>>> 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 >>>>
>>>> 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 >>>>> >>>>> 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.
On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez
wrote: the - 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/