<div dir="ltr">Are you sure the patch was applied correctly? I was SO sure it would work!<div><br></div><div>FYI, you tried the patch I attached to the email message, right?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 30, 2015 at 12:58 PM, Cyd Haselton <span dir="ltr"><<a href="mailto:chaselton@gmail.com" target="_blank">chaselton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Update: I did try the patch after getting it installed correctly, but<br>
I'm still getting a segfault on the newly built binary.<br>
Will post info this afternoon.<br>
<span class="im HOEnZb"><br>
On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <<a href="mailto:rymg19@gmail.com">rymg19@gmail.com</a>> wrote:<br>
</span><div class="HOEnZb"><div class="h5">> No, it returns NULL if malloc gives it a raw pointer. It unconditionally<br>
> checks the length of the (possibly null) string argument first.<br>
><br>
> Please try the patch I attached in the last email. It *might* fix the issue.<br>
> Android has crappy locale handling.<br>
><br>
> On Fri, Jan 30, 2015 at 12:09 PM, Cyd Haselton <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>> wrote:<br>
>><br>
>> Unless i'm reading something incorrectly, _PyMem_RawStrdup is<br>
>> currently returning NULL when given a null pointer.<br>
>><br>
>> From obmalloc.c<br>
>><br>
>> _PyMem_RawStrdup(const char *str)<br>
>> {<br>
>> size_t size;<br>
>> char *copy;<br>
>> size = strlen(str) + 1;<br>
>> copy = PyMem_RawMalloc(size);<br>
>> if (copy == NULL)<br>
>> return NULL;<br>
>> memcpy(copy, str, size);<br>
>> return copy;<br>
>> }<br>
>><br>
>> On Fri, Jan 30, 2015 at 11:56 AM, Ryan Gonzalez <<a href="mailto:rymg19@gmail.com">rymg19@gmail.com</a>> wrote:<br>
>> > I seriously doubt the issue is in that file; _PyMem_RawStrdup crashes<br>
>> > when<br>
>> > calling strlen. It's that whatever is calling it is likely asking it to<br>
>> > duplicate a null pointer. Basically, it's probably the caller's fault.<br>
>> ><br>
>> > You could always try modifying _PyMem_RawStrdup to return NULL when<br>
>> > given a<br>
>> > null pointer and see where it then segfaults.<br>
>> ><br>
>> > On Fri, Jan 30, 2015 at 11:53 AM, Cyd Haselton <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Alternatively, is there a hassle-free way to find out what changed in<br>
>> >> obmalloc.c between 2.7.x and 3.4.x?<br>
>> >><br>
>> >><br>
>> >> On Fri, Jan 30, 2015 at 9:29 AM, Cyd Haselton <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > There's a related strdup patch for readline.c, mentioned<br>
>> >> > here:<a href="http://bugs.python.org/issue21390" target="_blank">http://bugs.python.org/issue21390</a> and here<br>
>> >> > <a href="https://github.com/rave-engine/python3-android/issues/2" target="_blank">https://github.com/rave-engine/python3-android/issues/2</a>.<br>
>> >> > There's a patch, but I'm not sure how to modify it for obmalloc.c, as<br>
>> >> > (I think) the functions all belong to Python...they're all prefixed<br>
>> >> > with _PyXx<br>
>> >> ><br>
>> >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >> Absolutely. Good thing I have addr2line on device<br>
>> >> >><br>
>> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e<br>
>> >> >> /lib/libpython3.4m.so.1.0<br>
>> >> >> 0008bbc8<br>
>> >> >> _PyMem_RawStrdup<br>
>> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323<br>
>> >> >> /bld/python/Python-3.4.2 $<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan <<a href="mailto:rymg19@gmail.com">rymg19@gmail.com</a>> wrote:<br>
>> >> >>> Could you try the steps at<br>
>> >> >>> <a href="http://stackoverflow.com/a/11369475/2097780" target="_blank">http://stackoverflow.com/a/11369475/2097780</a>? They<br>
>> >> >>> allow you to get a better idea of where libc is crashing.<br>
>> >> >>><br>
>> >> >>> Cyd Haselton <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>> wrote:<br>
>> >> >>>><br>
>> >> >>>> Managed to get this out of logcat:<br>
>> >> >>>> F(11914) Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread<br>
>> >> >>>> 11914 (python) (libc)<br>
>> >> >>>><br>
>> >> >>>> [ 01-29 19:30:55.855 23373:23373 F/libc ]<br>
>> >> >>>> Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 23373<br>
>> >> >>>> (python)<br>
>> >> >>>><br>
>> >> >>>> Less detail than strace but it seems to be that python is<br>
>> >> >>>> segfaulting<br>
>> >> >>>> libc...<br>
>> >> >>>><br>
>> >> >>>> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez <<a href="mailto:rymg19@gmail.com">rymg19@gmail.com</a>><br>
>> >> >>>> wrote:<br>
>> >> >>>>><br>
>> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum<br>
>> >> >>>>> <<a href="mailto:guido@python.org">guido@python.org</a>><br>
>> >> >>>>> wrote:<br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>> What I see in the strace:<br>
>> >> >>>>>><br>
>> >> >>>>>> ... load libpython3.4m.so.1.0<br>
>> >> >>>>>> ... load libm<br>
>> >> >>>>>> ... open /dev/__properties__ and do something to it<br>
>> >> >>>>>> (what?)<br>
>> >> >>>>>> ... get current time<br>
>> >> >>>>>> ... allocate memory<br>
>> >> >>>>>> ... getuid<br>
>> >> >>>>>> ... segfault<br>
>> >> >>>>>><br>
>> >> >>>>>> That's not a lot to go on, but it doesn't look as if it has<br>
>> >> >>>>>> started to<br>
>> >> >>>>>> load modules yet.<br>
>> >> >>>>>><br>
>> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me.<br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>> <a href="https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c" target="_blank">https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c</a><br>
>> >> >>>>> is the code that works with that file.<br>
>> >> >>>>><br>
>> >> >>>>> This explains it a bit (slides 24-29). Looks like something to<br>
>> >> >>>>> do<br>
>> >> >>>>> with<br>
>> >> >>>>> interprocess communication. Likely has nothing to do with Python<br>
>> >> >>>>> itself.<br>
>> >> >>>>><br>
>> >> >>>>> Maybe this would be useful?<br>
>> >> >>>>><br>
>> >> >>>>>><br>
>> >> >>>>>> That stack trace would be really helpful.<br>
>> >> >>>>>><br>
>> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton<br>
>> >> >>>>>> <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>><br>
>> >> >>>>>> wrote:<br>
>> >> >>>>>>><br>
>> >> >>>>>>><br>
>> >> >>>>>>> Apologies...I'm not sure what a stack track is, but I do have<br>
>> >> >>>>>>> the<br>
>> >> >>>>>>> strace. Nearest I can tell, it happens due to an open call,<br>
>> >> >>>>>>> though I<br>
>> >> >>>>>>> am probably wrong.<br>
>> >> >>>>>>> Attaching the strace output to this email. I'm going to head<br>
>> >> >>>>>>> back to<br>
>> >> >>>>>>> the documentation and to back out of some Android-related<br>
>> >> >>>>>>> changes<br>
>> >> >>>>>>> in<br>
>> >> >>>>>>> _localemodule.c<br>
>> >> >>>>>>><br>
>> >> >>>>>>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum<br>
>> >> >>>>>>> <<a href="mailto:guido@python.org">guido@python.org</a>><br>
>> >> >>>>>>> wrote:<br>
>> >> >>>>>>>><br>
>> >> >>>>>>>> There could be a million differences relevant (unicode, ints,<br>
>> >> >>>>>>>> ...).<br>
>> >> >>>>>>>> Perhaps<br>
>> >> >>>>>>>> the importlib bootstrap is failing. Perhaps the dynamic<br>
>> >> >>>>>>>> loading<br>
>> >> >>>>>>>> code<br>
>> >> >>>>>>>> changed. Did you get a stack track? (IIRC strace shows a<br>
>> >> >>>>>>>> syscall<br>
>> >> >>>>>>>> trace<br>
>> >> >>>>>>>> --<br>
>> >> >>>>>>>> also useful, but doesn't tell you precisely how<br>
>> >> >>>>>>>> it segfaulted.)<br>
>> >> >>>>>>>><br>
>> >> >>>>>>>> On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton<br>
>> >> >>>>>>>> <<a href="mailto:chaselton@gmail.com">chaselton@gmail.com</a>><br>
>> >> >>>>>>>> wrote:<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> All,<br>
>> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to<br>
>> >> >>>>>>>>> Android<br>
>> >> >>>>>>>>> in<br>
>> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same<br>
>> >> >>>>>>>>> configure<br>
>> >> >>>>>>>>> options in the same environment, and modifying the setup.py<br>
>> >> >>>>>>>>> as<br>
>> >> >>>>>>>>> needed,<br>
>> >> >>>>>>>>> the newly built binary throws a segfault when the<br>
>> >> >>>>>>>>> generate-posix-vars<br>
>> >> >>>>>>>>> portion of the build is reached...and when it is run as well<br>
>> >> >>>>>>>>> (i.e.<br>
>> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar)<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when<br>
>> >> >>>>>>>>> reviewing<br>
>> >> >>>>>>>>> it.<br>
>> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7<br>
>> >> >>>>>>>>> works but<br>
>> >> >>>>>>>>> 3.x throws a segfault?<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> Thanks in advance,<br>
>> >> >>>>>>>>> Cyd<br>
>> >> >>>>>>>>> ________________________________<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> Python-Dev mailing list<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
>> >> >>>>>>>>> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>> >> >>>>>>>>> Unsubscribe:<br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>><br>
>> >> >>>>>>>>> <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
>> >> >>>>>>>><br>
>> >> >>>>>>>><br>
>> >> >>>>>>>><br>
>> >> >>>>>>>><br>
>> >> >>>>>>>><br>
>> >> >>>>>>>> --<br>
>> >> >>>>>>>> --Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>> --<br>
>> >> >>>>>> --Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)<br>
>> >> >>>>>><br>
>> >> >>>>>> ________________________________<br>
>> >> >>>>>><br>
>> >> >>>>>> Python-Dev mailing list<br>
>> >> >>>>>> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
>> >> >>>>>> <a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
>> >> >>>>>> Unsubscribe:<br>
>> >> >>>>>><br>
>> >> >>>>>><br>
>> >> >>>>>> <a href="https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com</a><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>><br>
>> >> >>>>> --<br>
>> >> >>>>> Ryan<br>
>> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be<br>
>> >> >>>>> simple:<br>
>> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think<br>
>> >> >>>>> that was<br>
>> >> >>>>> nul-terminated."<br>
>> >> >>>>> Personal reality distortion fields are immune to contradictory<br>
>> >> >>>>> evidence.<br>
>> >> >>>>> -<br>
>> >> >>>>> srean<br>
>> >> >>>>> Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a><br>
>> >> >>><br>
>> >> >>><br>
>> >> >>> --<br>
>> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.<br>
>> >> >>> Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Ryan<br>
>> > If anybody ever asks me why I prefer C++ to C, my answer will be simple:<br>
>> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was<br>
>> > nul-terminated."<br>
>> > Personal reality distortion fields are immune to contradictory evidence.<br>
>> > -<br>
>> > srean<br>
>> > Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Ryan<br>
> If anybody ever asks me why I prefer C++ to C, my answer will be simple:<br>
> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was<br>
> nul-terminated."<br>
> Personal reality distortion fields are immune to contradictory evidence. -<br>
> srean<br>
> Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Ryan<div><div>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."</div></div>Personal reality distortion fields are immune to contradictory evidence. - srean<div>Check out my website: <a href="http://kirbyfan64.github.io/" target="_blank">http://kirbyfan64.github.io/</a></div></div></div>
</div>