Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault

Are you sure the patch was applied correctly? I was SO sure it would work! FYI, you tried the patch I attached to the email message, right? On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton wrote:

Update: I did try the patch after getting it installed correctly, but I'm still getting a segfault on the newly built binary. Will post info this afternoon.

...

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 wrote:

...

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; }

On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez

wrote:

...

...

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),

...

...

...

...

...

>>> 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 < rymg19@gmail.com> >>> 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 >>>>>> 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

...

...

...

...

...

>>>>>> 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

...

...

...

...

...

>>>> 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.

On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez wrote: thread head think -

...

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/