Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com wrote:
Yes I did. I did have to enter all the information in manually...I'm not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you wanted all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com wrote:
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 chaselton@gmail.com 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.
On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez rymg19@gmail.com wrote:
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 chaselton@gmail.com 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 rymg19@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@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@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@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@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@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@gmail.com >> >>>> 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 >> >>>>>> chaselton@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@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 >> >>>>> 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.
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/
-- 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/
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not) work:
1. Make sure you have a copy of Python on your computer and make sure that it's built with debug symbols.
2. Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python executable> <path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com
wrote:
Yes I did. I did have to enter all the information in manually...I'm not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you wanted all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
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 chaselton@gmail.com 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.
On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez rymg19@gmail.com wrote:
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 <
chaselton@gmail.com>
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 <rymg19@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@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@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@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@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@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@gmail.com > >> >>>> 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 > >> >>>>>> chaselton@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@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 > >> >>>>> 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.
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/
-- 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/
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends against it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK installed. If I am able to get it back up and running, there's still the task of getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would be far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not) work:
- Make sure you have a copy of Python on your computer and make sure that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python executable> <path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com wrote:
Yes I did. I did have to enter all the information in manually...I'm not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you wanted all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com wrote:
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 chaselton@gmail.com 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.
On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez rymg19@gmail.com wrote: > 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 > chaselton@gmail.com > 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 >> rymg19@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@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@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@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@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@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@gmail.com >> >> >>>> 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 >> >> >>>>>> chaselton@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@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 >> >> >>>>> 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. > - > 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/
-- 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. - srean Check out my website: http://kirbyfan64.github.io/
Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends against it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK installed. If I am able to get it back up and running, there's still the task of getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would be far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not) work:
- Make sure you have a copy of Python on your computer and make sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python executable> <path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com wrote:
Yes I did. I did have to enter all the information in manually...I'm not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you
wanted
all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com wrote:
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 <
chaselton@gmail.com>
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. > > On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <rymg19@gmail.com
> wrote: > > 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 > > chaselton@gmail.com > > 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 > >> rymg19@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@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@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@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@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@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@gmail.com > >> >> >>>> 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 > >> >> >>>>>> chaselton@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@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 > >> >> >>>>> 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. > > - > > 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/
-- 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.
srean Check out my website: http://kirbyfan64.github.io/
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends against it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK installed. If I am able to get it back up and running, there's still the task of getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would be far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not) work:
- Make sure you have a copy of Python on your computer and make sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python executable> <path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com wrote:
Yes I did. I did have to enter all the information in
manually...I'm
not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you
wanted
all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com wrote: > 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 <
chaselton@gmail.com>
> 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. >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
>> wrote: >> > 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 >> > chaselton@gmail.com >> > 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 >> >> rymg19@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@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@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@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@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@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@gmail.com >> >> >> >>>> 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 >> >> >> >>>>>> chaselton@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@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 >> >> >> >>>>> 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. >> > - >> > 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/
-- 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. -
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/
I don't have the SDK either...but my device is rooted.
Dual-booting is not an option unfortunately...space reasons. I'll do my best to figure out a way to get the instuctions you sent implemented, but this may be a deal-breaker for porting Python 3.4.x for me...I may go back to working on 2.7.x
Sent from my android device.
-----Original Message----- From: Ryan Gonzalez rymg19@gmail.com To: Cyd Haselton chaselton@gmail.com Cc: Python-Dev python-dev@python.org Sent: Fri, 30 Jan 2015 7:53 PM Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends against it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK installed. If I am able to get it back up and running, there's still the task of getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would be far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may not) work:
- Make sure you have a copy of Python on your computer and make sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python executable> <path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB, type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton chaselton@gmail.com wrote:
Yes I did. I did have to enter all the information in
manually...I'm
not familiar with automated patch application tools and even if I were, I'm pretty sure I wouldn't have them on my device.
Just so that I'm absolutely sure I got everything correct...you
wanted
all of the lines in the patch commented out, correct? Basically everything referencing oldloc?
On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez rymg19@gmail.com wrote: > 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 <
chaselton@gmail.com>
> 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. >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
>> wrote: >> > 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 >> > chaselton@gmail.com >> > 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 >> >> rymg19@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@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@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@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@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@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@gmail.com >> >> >> >>>> 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 >> >> >> >>>>>> chaselton@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@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 >> >> >> >>>>> 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. >> > - >> > 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/
-- 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. -
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/
Ok...try this (based on http://dan.drown.org/android/howto/gdb.html):
- Install BusyBox and a Terminal Emulator - Inside the Terminal Emulator, run:
su cd /data/local/tmp wget http://dan.drown.org/android/gdb- static.tar.gz tar zxf gdb-static.tar.gz ./gdb <path to python interpreter>
Now, inside gdb, type:
set logging file /mnt/sdcard/bt.txt set logging on run
Wait for Python to crash, then type:
backtrace
A backtrace should be printed to the screen and saved to a file named bt.txt on the SD card. After that, type:
quit
to quit GDB. Send the list the bt.txt file on your SD card.
chaselton@gmail.com wrote:
I don't have the SDK either...but my device is rooted.
Dual-booting is not an option unfortunately...space reasons. I'll do my best to figure out a way to get the instuctions you sent implemented, but this may be a deal-breaker for porting Python 3.4.x for me...I may go back to working on 2.7.x
Sent from my android device.
-----Original Message----- From: Ryan Gonzalez rymg19@gmail.com To: Cyd Haselton chaselton@gmail.com Cc: Python-Dev python-dev@python.org Sent: Fri, 30 Jan 2015 7:53 PM Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
wrote: > > Yes I did. I did have to enter all the information in
manually...I'm
> not familiar with automated patch application tools and even
if I
> were, I'm pretty sure I wouldn't have them on my device. > > Just so that I'm absolutely sure I got everything
correct...you
wanted
> all of the lines in the patch commented out, correct?
Basically
> everything referencing oldloc? > > On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
> wrote: > > 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 <
chaselton@gmail.com>
> > 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. > >> > >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
> >> wrote: > >> > 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 > >> > chaselton@gmail.com > >> > 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 > >> >> rymg19@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@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@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@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@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@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@gmail.com > >> >> >> >>>> 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 > >> >> >> >>>>>> chaselton@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@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 > >> >> >> >>>>> that was > >> >> >> >>>>> nul-terminated." > >> >> >> >>>>> Personal reality distortion fields are immune
to
> >> >> >> >>>>> contradictory > >> >> >> >>>>> evidence. > >> >> >> >>>>> - > >> >> >> >>>>> srean > >> >> >> >>>>> Check out my website:
> >> >> >> >>> > >> >> >> >>> > >> >> >> >>> -- > >> >> >> >>> Sent from my Android phone with K-9 Mail. Please
excuse my
> >> >> >> >>> brevity. > >> >> >> >>> Check out my website:
> >> >> > > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > 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. > >> > - > >> > 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/
-- 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. -
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/
-- 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/
Ergh...this may not work. I've already got BusyBox and a terminal installed, but the python build...and all other utilities that I use...are running in a fakechrooted environment inside the terminal. That environment only filters dynamic calls to libc, so the statically compiled gdb won't work in the environment and running it outside the environment against the python built IN the environment won't work, I think...
Let me do some looking around and tinkering...I may just need to build gdb for my environment.
On January 31, 2015 1:09:22 PM CST, Ryan rymg19@gmail.com wrote:
Ok...try this (based on http://dan.drown.org/android/howto/gdb.html):
- Install BusyBox and a Terminal Emulator
- Inside the Terminal Emulator, run:
su cd /data/local/tmp wget http://dan.drown.org/android/gdb- static.tar.gz tar zxf gdb-static.tar.gz ./gdb <path to python interpreter>
Now, inside gdb, type:
set logging file /mnt/sdcard/bt.txt set logging on run
Wait for Python to crash, then type:
backtrace
A backtrace should be printed to the screen and saved to a file named bt.txt on the SD card. After that, type:
quit
to quit GDB. Send the list the bt.txt file on your SD card.
chaselton@gmail.com wrote:
I don't have the SDK either...but my device is rooted.
Dual-booting is not an option unfortunately...space reasons. I'll do my best to figure out a way to get the instuctions you sent implemented, but this may be a deal-breaker for porting Python 3.4.x for me...I may go back to working on 2.7.x
Sent from my android device.
-----Original Message----- From: Ryan Gonzalez rymg19@gmail.com To: Cyd Haselton chaselton@gmail.com Cc: Python-Dev python-dev@python.org Sent: Fri, 30 Jan 2015 7:53 PM Subject: Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now
I
rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have
to
clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or
may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone
plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez
wrote:
> Yes... > > Can you check if it's crashing in a different function now? > > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
> wrote: >> >> Yes I did. I did have to enter all the information in
manually...I'm
>> not familiar with automated patch application tools and even
if I
>> were, I'm pretty sure I wouldn't have them on my device. >> >> Just so that I'm absolutely sure I got everything
correct...you
wanted
>> all of the lines in the patch commented out, correct?
Basically
>> everything referencing oldloc? >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
>> wrote: >> > 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 <
chaselton@gmail.com>
>> > 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. >> >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
>> >> wrote: >> >> > 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 >> >> > chaselton@gmail.com >> >> > 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 >> >> >> rymg19@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@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@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@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@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@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... >> >> >> >> >>
Question: When you said earlier that you found the problem by using grep...were you looking for places where strdup called locale?
On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez rymg19@gmail.com wrote:
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Yes...
Can you check if it's crashing in a different function now?
On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
wrote: > > Yes I did. I did have to enter all the information in
manually...I'm
> not familiar with automated patch application tools and even
if I
> were, I'm pretty sure I wouldn't have them on my device. > > Just so that I'm absolutely sure I got everything
correct...you
wanted
> all of the lines in the patch commented out, correct?
Basically
> everything referencing oldloc? > > On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
> wrote: > > 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 <
chaselton@gmail.com>
> > 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. > >> > >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
> >> wrote: > >> > 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 > >> > chaselton@gmail.com > >> > 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 > >> >> rymg19@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@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@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@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@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@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@gmail.com > >> >> >> >>>> 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...
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times.
Cyd Haselton chaselton@gmail.com wrote:
Question: When you said earlier that you found the problem by using grep...were you looking for places where strdup called locale?
On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez rymg19@gmail.com wrote:
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now
I
rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have
to
clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or
may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone
plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
Unfortunately it is still reporting the same function :-/.
On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez
wrote:
> Yes... > > Can you check if it's crashing in a different function now? > > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
> wrote: >> >> Yes I did. I did have to enter all the information in
manually...I'm
>> not familiar with automated patch application tools and even
if I
>> were, I'm pretty sure I wouldn't have them on my device. >> >> Just so that I'm absolutely sure I got everything
correct...you
wanted
>> all of the lines in the patch commented out, correct?
Basically
>> everything referencing oldloc? >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
>> wrote: >> > 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 <
chaselton@gmail.com>
>> > 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. >> >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
>> >> wrote: >> >> > 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 >> >> > chaselton@gmail.com >> >> > 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 >> >> >> rymg19@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@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@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@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@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@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@gmail.com >> >> >> >> >>>> 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...
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
There were references to oldloc in Modules/python.c...a duplicate of the line in frozenmain.c and some others. On a hunch I commented them out, ran make clean && make.
If it fails, I'll revert and use the method you sent in the email after this (thanks...by the way!)
On January 31, 2015 1:10:18 PM CST, Ryan rymg19@gmail.com wrote:
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times.
Cyd Haselton chaselton@gmail.com wrote:
Question: When you said earlier that you found the problem by using grep...were you looking for places where strdup called locale?
On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez rymg19@gmail.com wrote:
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now
I
rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have
to
clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can
a)
run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or
may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone
plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To
GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
> > Unfortunately it is still reporting the same function :-/. > > On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez
wrote:
> > Yes... > > > > Can you check if it's crashing in a different function now? > > > > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
> > wrote: > >> > >> Yes I did. I did have to enter all the information in
manually...I'm
> >> not familiar with automated patch application tools and even
if I
> >> were, I'm pretty sure I wouldn't have them on my device. > >> > >> Just so that I'm absolutely sure I got everything
correct...you
wanted
> >> all of the lines in the patch commented out, correct?
Basically
> >> everything referencing oldloc? > >> > >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
> >> wrote: > >> > 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 <
chaselton@gmail.com>
> >> > 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. > >> >> > >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
> >> >> wrote: > >> >> > 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 > >> >> > chaselton@gmail.com > >> >> > 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 > >> >> >> rymg19@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@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@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@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@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@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@gmail.com > >> >> >> >> >>>> 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/__properti
Very interesting. I got this error
Fatal Python error: Py_Initialize: Unable to get the locale encoding NotImplementedError Aborted generate-posix-vars failed make: *** [pybuilddir.txt] Error 1
...but it didn't (of course) segfault. I'll pull gdb, get the results and send them.
On January 31, 2015 1:10:18 PM CST, Ryan rymg19@gmail.com wrote:
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times.
Cyd Haselton chaselton@gmail.com wrote:
Question: When you said earlier that you found the problem by using grep...were you looking for places where strdup called locale?
On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez rymg19@gmail.com wrote:
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now
I
rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted
phone?
If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com
wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have
to
clear some space...but my primary machine is running Windows 7 and
I'd
rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends
against
it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK
installed.
If I am able to get it back up and running, there's still the task
of
getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest).
In
the meantime I'll also check to see if there's anything that can
a)
run in an Android terminal and b) can take a stack trace; it would
be
far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com
wrote:
Do you have the Android SDK and NDK installed? If so...
Using Google, I've created this series of steps, which may (or
may
not)
work:
- Make sure you have a copy of Python on your computer and make
sure
that
it's built with debug symbols.
- Run the following commands from a shell with your phone
plugged
in:
adb forward tcp:5039 tcp:5039 adb shell /system/bin/gdbserver tcp:5039 <path to python
executable>
<path to ndk binary folder>/arm-linux-androideabi-gdb
Now, GDB should have opened, so type the following commands:
set solib-search-path <directory holder libpython.so> file <path to local python executable> target remote :5055 run
Now, wait for the program to crash and type:
backtrace
You should now see a complete backtrace in your terminal. To
GDB,
type:
quit
*crosses fingers*
On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton
wrote:
> > Unfortunately it is still reporting the same function :-/. > > On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez
wrote:
> > Yes... > > > > Can you check if it's crashing in a different function now? > > > > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton
> > wrote: > >> > >> Yes I did. I did have to enter all the information in
manually...I'm
> >> not familiar with automated patch application tools and even
if I
> >> were, I'm pretty sure I wouldn't have them on my device. > >> > >> Just so that I'm absolutely sure I got everything
correct...you
wanted
> >> all of the lines in the patch commented out, correct?
Basically
> >> everything referencing oldloc? > >> > >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez
> >> wrote: > >> > 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 <
chaselton@gmail.com>
> >> > 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. > >> >> > >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez <
rymg19@gmail.com>
> >> >> wrote: > >> >> > 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 > >> >> > chaselton@gmail.com > >> >> > 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 > >> >> >> rymg19@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@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@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@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@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@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@gmail.com > >> >> >> >> >>>> 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/__properti
That looks better! Looks like now the real encoding issues are coming up. Try going to line 269 of pythonrun.c and changing:
PyErr_SetNone(PyExc_NotImplementedError); return NULL;
to:
char* m = malloc(6); strcpy(m, "ascii"); return m;
This just sets a default encoding.
On Sat, Jan 31, 2015 at 1:21 PM, Cyd Haselton chaselton@gmail.com wrote:
Very interesting. I got this error
Fatal Python error: Py_Initialize: Unable to get the locale encoding NotImplementedError Aborted generate-posix-vars failed make: *** [pybuilddir.txt] Error 1
...but it didn't (of course) segfault. I'll pull gdb, get the results and send them.
On January 31, 2015 1:10:18 PM CST, Ryan rymg19@gmail.com wrote:
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times.
Cyd Haselton chaselton@gmail.com wrote:
Question: When you said earlier that you found the problem by using grep...were you looking for places where strdup called locale?
On January 30, 2015 7:52:47 PM CST, Ryan Gonzalez rymg19@gmail.com wrote:
Regardless, if you're looking to toy more with stuff like this, I'd highly recommend dual-booting with Ubuntu, which is what I'm doing now. (Now I rarely ever boot into Windows!)
On Fri, Jan 30, 2015 at 7:51 PM, Ryan Gonzalez rymg19@gmail.com wrote:
Do you have just the SDK (which doesn't require Cygwin) or a rooted phone? If so, I can upload instructions that don't use the NDK.
On Fri, Jan 30, 2015 at 6:19 PM, Cyd Haselton chaselton@gmail.com wrote:
This is going to take some time...here's why:
Downloading and installing the NDK/SDK won't be too hard...I have to clear some space...but my primary machine is running Windows 7 and I'd rather swallow hot coals than install Cygwin. I've got next to no experience with it, other than knowing that the NDK recommends against it.
I've got a CentOS VM...but it's currently in tarball form on an external drive for space reasons...and it only has the NDK installed. If I am able to get it back up and running, there's still the task of getting adb connected to my device. from the VM.
Not saying it's impossible...just that it'll take time...and I'll probably have to tackle it tomorrow (earliest) or Sunday (latest). In the meantime I'll also check to see if there's anything that can a) run in an Android terminal and b) can take a stack trace; it would be far, far, far easier than either option above.
On Fri, Jan 30, 2015 at 4:19 PM, Ryan Gonzalez rymg19@gmail.com wrote: > Do you have the Android SDK and NDK installed? If so... > > Using Google, I've created this series of steps, which may (or may not) > work: > > 1. Make sure you have a copy of Python on your computer and make sure that > it's built with debug symbols. > > 2. Run the following commands from a shell with your phone plugged in: > > adb forward tcp:5039 tcp:5039 > adb shell /system/bin/gdbserver tcp:5039 <path to python executable> > <path to ndk binary folder>/arm-linux-androideabi-gdb > > Now, GDB should have opened, so type the following commands: > > set solib-search-path <directory holder libpython.so> > file <path to local python executable> > target remote :5055 > run > > Now, wait for the program to crash and type: > > backtrace > > You should now see a complete backtrace in your terminal. To GDB, type: > > quit > > *crosses fingers* > > On Fri, Jan 30, 2015 at 2:50 PM, Cyd Haselton chaselton@gmail.com wrote: >> >> Unfortunately it is still reporting the same function :-/. >> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez rymg19@gmail.com wrote: >> > Yes... >> > >> > Can you check if it's crashing in a different function now? >> > >> > On Fri, Jan 30, 2015 at 1:39 PM, Cyd Haselton < chaselton@gmail.com> >> > wrote: >> >> >> >> Yes I did. I did have to enter all the information in manually...I'm >> >> not familiar with automated patch application tools and even if I >> >> were, I'm pretty sure I wouldn't have them on my device. >> >> >> >> Just so that I'm absolutely sure I got everything correct...you wanted >> >> all of the lines in the patch commented out, correct? Basically >> >> everything referencing oldloc? >> >> >> >> On Fri, Jan 30, 2015 at 1:00 PM, Ryan Gonzalez < rymg19@gmail.com> >> >> wrote: >> >> > 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 < chaselton@gmail.com> >> >> > 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. >> >> >> >> >> >> On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez < rymg19@gmail.com> >> >> >> wrote: >> >> >> > 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 >> >> >> > chaselton@gmail.com >> >> >> > 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 >> >> >> >> rymg19@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@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@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@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@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@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@gmail.com >> >> >> >> >> >>>> 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 >> >> >> >> >> >>>>>> chaselton@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@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 >> >> >> >> >> >>>>> 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. >> >> >> > - >> >> >> > 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/ >> > >> > >> > >> > >> > -- >> > 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. - > 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/
-- 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 device with K-9 Mail. Please excuse my brevity.
participants (4)
-
chaselton＠gmail.com -
Cyd Haselton
-
Ryan -
Ryan Gonzalez