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 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 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 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
>> > /arm-linux-androideabi-gdb
>> >
>> > Now, GDB should have opened, so type the following commands:
>> >
>> > set solib-search-path
>> > file
>> > 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 <
>> chasel...@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
>> >> >> >> >
>> >> >> >> > 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
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
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 To: Cyd Haselton Cc: Python-Dev 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 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 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 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 >> > /arm-linux-androideabi-gdb >> > >> > Now, GDB should have opened, so type the following commands: >> > >> > set solib-search-path >> > file >> > 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 < >> chasel...@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 >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> Unless i'm reading something incorrectly, _PyMem_RawStrdup >> is >> >> >> >> >> currently returning NULL when given a null pointer. >> >> >>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
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 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
>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
>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
>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 executable>
>>> > /arm-linux-androideabi-gdb
>>> >
>>> > Now, GDB should have opened, so type the following commands:
>>> >
>>> > set solib-search-path
>>> > file
>>> > 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 <
>>> chasel...@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
>>> >> >> >> >
>>> >> >> >> > 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;
>>>
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's used only a few times. Cyd Haselton 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 >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 >>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 >>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 >>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 >executable> > /arm-linux-androideabi-gdb > > Now, GDB should have opened, so type the following commands: > > set solib-search-path > file > 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 < chasel...@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 >> >> >> > >> >> >> > wrote: >> >> >> >> >> >> >> >> Unless i'm reading something i
Re: [Python-Dev] Newly Built Python3 Binary Throws Segfault
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 wrote: >No; I was looking for all uses of _PyRaw_Strdup. Surprisingly, it's >used only a few times. > >Cyd Haselton 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 >>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 >>>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 >>>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 >>>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 >>executable> > > /arm-linux-androideabi-gdb > > > > Now, GDB should have opened, so type the following commands: > > > > set solib-search-path > > file > > 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 < > chasel...@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 > >> >> >> > uncond
[Python-Dev] Workflow improvement PEPs 474 & 462 updated
As per Brett's target timeline, I've just posted updated versions of my workflow improvement proposals in PEP 474 and 462 PEP 474 is my proposal to host a Kallithea instance at forge.python.org: https://www.python.org/dev/peps/pep-0474/ This update was fairly minor, mainly just added some timeline details based on Brett's proposed schedule for discussions and implementation: https://www.python.org/dev/peps/pep-0474/#pilot-objectives-and-timeline The updates to PEP 462, which covers proposed changes to the main CPython workflow, were more significant, as I've now rewritten that to depend on PEP 474, and propose replacing the current Rietveld patch review workflow with an updated approach based on Kallithea and Zuul: https://www.python.org/dev/peps/pep-0462/ Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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/archive%40mail-archive.com
