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

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 <rym...@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.>>chas...@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 <rym...@gmail.com>>>To: Cyd Haselton <chas...@gmail.com>>>Cc: Python-Dev <pyth...@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 <rym...@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 <chas...@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 <rym...@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>><chas...@gmail.com>>>>> wrote:>>>> >>>>>> >> Unfortunately it is still reporting the same function :-/.>>>> >>>>>> >> On Fri, Jan 30, 2015 at 1:44 PM, Ryan Gonzalez><rym...@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>><chas...@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>><rym...@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 <>>>> chas...@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 <>>>> rym...@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>>>> >> >> >> > <chas...@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>>>> >> >> >> >> <rym...@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>>>> >> >> >> >> > <chas...@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>>>> >> >> >> >> >> <chas...@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>>>> >> >> >> >> >> > <chas...@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>><rym...@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 <chas...@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...>>>> >> >> >> >> >> >>
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.