[Python-Dev] Newly Built Python3 Binary Throws Segfault

Cyd Haselton chaselton at gmail.com
Fri Jan 30 19:09:01 CET 2015 

  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 <rymg19 at gmail.com> 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 <chaselton at gmail.com> 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 <chaselton at gmail.com> 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 <chaselton at 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 <rymg19 at 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 <chaselton at 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 <rymg19 at gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>  On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum
>> >>>>> <guido at 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
>> >>>>>> <chaselton at 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
>> >>>>>>> <guido at 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 at 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 at 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 at 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/

More information about the Python-Dev mailing list