at 0x10160b7c0, file " ", line 1>) 3 LOAD_CONST 1 (' ') 6 MAKE_FUNCTION 0 9 LOAD_CONST 2 (2) 12 LOAD_CONST 3 (1) 15 BUILD_MAP 1 18 BUILD_LIST 1 21 GET_ITER 22 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 25 RETURN_VALUE (This requires the new patch in issue 2292.) The code here looks fine to me, so I need to look into the code object . How do I do that? Thanks, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From mistersheik at gmail.com Sun Jan 25 13:12:02 2015 From: mistersheik at gmail.com (Neil Girdhar) Date: Sun, 25 Jan 2015 07:12:02 -0500 Subject: [Python-Dev] Disassembly of generated comprehensions In-Reply-To: References: Message-ID: Perfect, thanks! On Sun, Jan 25, 2015 at 7:08 AM, Petr Viktorin wrote: > On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar > wrote: > > How do I disassemble a generated comprehension? > > > > For example, I am trying to debug the following: > > > >>>> dis.dis('{**{} for x in [{1:2}]}') > > 1 0 LOAD_CONST 0 ( at > > 0x10160b7c0, file " ", line 1>) > > 3 LOAD_CONST 1 (' ') > > 6 MAKE_FUNCTION 0 > > 9 LOAD_CONST 2 (2) > > 12 LOAD_CONST 3 (1) > > 15 BUILD_MAP 1 > > 18 BUILD_LIST 1 > > 21 GET_ITER > > 22 CALL_FUNCTION 1 (1 positional, 0 keyword pair) > > 25 RETURN_VALUE > > > > (This requires the new patch in issue 2292.) > > > > The code here looks fine to me, so I need to look into the code object > > . How do I do that? > > Put it in a function, then get it from the function's code's constants. > I don't have the patch applied but it should work like this even for > the new syntax: > > >>> import dis > >>> def f(): return {{} for x in [{1:2}]} > ... > >>> dis.dis(f) > 1 0 LOAD_CONST 1 ( at > 0x7ff2c0647420, file " ", line 1>) > 3 LOAD_CONST 2 ('f. . ') > 6 MAKE_FUNCTION 0 > 9 BUILD_MAP 1 > 12 LOAD_CONST 3 (2) > 15 LOAD_CONST 4 (1) > 18 STORE_MAP > 19 BUILD_LIST 1 > 22 GET_ITER > 23 CALL_FUNCTION 1 (1 positional, 0 keyword pair) > 26 RETURN_VALUE > >>> f.__code__.co_consts[1] # from "LOAD_CONST 1" > at 0x7ff2c0647420, file " ", line 1> > >>> dis.dis(f.__code__.co_consts[1]) > 1 0 BUILD_SET 0 > 3 LOAD_FAST 0 (.0) > >> 6 FOR_ITER 12 (to 21) > 9 STORE_FAST 1 (x) > 12 BUILD_MAP 0 > 15 SET_ADD 2 > 18 JUMP_ABSOLUTE 6 > >> 21 RETURN_VALUE > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Sun Jan 25 16:07:53 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 25 Jan 2015 16:07:53 +0100 Subject: [Python-Dev] Can Python Be Built Without Distutils In-Reply-To: References: <54C29784.2080908@ubuntu.com> <54C29ED2.2050508@egenix.com> <54C40632.4020301@egenix.com> <20150124232430.49c859ca@fsol> Message-ID: <20150125160753.53b98d7b@fsol> On Sun, 25 Jan 2015 05:22:48 +0000 "Gregory P. Smith" wrote: > Why doesn't our Makefile supply that flag with the make parallelism level > in the sharedmods step? If I run "make -j4" here, it works (on the default branch). Regards Antoine. From solipsis at pitrou.net Sun Jan 25 16:08:54 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 25 Jan 2015 16:08:54 +0100 Subject: [Python-Dev] Any grammar experts? References: Message-ID: <20150125160854.36e785e0@fsol> On Sat, 24 Jan 2015 21:10:51 -0500 Neil Girdhar wrote: > To finish PEP 448, I need to update the grammar for syntax such as > > {**x for x in it} Is this seriously allowed by the PEP? What does it mean exactly? Regards Antoine. From encukou at gmail.com Sun Jan 25 13:08:57 2015 From: encukou at gmail.com (Petr Viktorin) Date: Sun, 25 Jan 2015 13:08:57 +0100 Subject: [Python-Dev] Disassembly of generated comprehensions In-Reply-To: References: Message-ID: On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar wrote: > How do I disassemble a generated comprehension? > > For example, I am trying to debug the following: > >>>> dis.dis('{**{} for x in [{1:2}]}') > 1 0 LOAD_CONST 0 ( at > 0x10160b7c0, file " ", line 1>) > 3 LOAD_CONST 1 (' ') > 6 MAKE_FUNCTION 0 > 9 LOAD_CONST 2 (2) > 12 LOAD_CONST 3 (1) > 15 BUILD_MAP 1 > 18 BUILD_LIST 1 > 21 GET_ITER > 22 CALL_FUNCTION 1 (1 positional, 0 keyword pair) > 25 RETURN_VALUE > > (This requires the new patch in issue 2292.) > > The code here looks fine to me, so I need to look into the code object > . How do I do that? Put it in a function, then get it from the function's code's constants. I don't have the patch applied but it should work like this even for the new syntax: >>> import dis >>> def f(): return {{} for x in [{1:2}]} ... >>> dis.dis(f) 1 0 LOAD_CONST 1 ( at 0x7ff2c0647420, file " ", line 1>) 3 LOAD_CONST 2 ('f. . ') 6 MAKE_FUNCTION 0 9 BUILD_MAP 1 12 LOAD_CONST 3 (2) 15 LOAD_CONST 4 (1) 18 STORE_MAP 19 BUILD_LIST 1 22 GET_ITER 23 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 26 RETURN_VALUE >>> f.__code__.co_consts[1] # from "LOAD_CONST 1" at 0x7ff2c0647420, file " ", line 1> >>> dis.dis(f.__code__.co_consts[1]) 1 0 BUILD_SET 0 3 LOAD_FAST 0 (.0) >> 6 FOR_ITER 12 (to 21) 9 STORE_FAST 1 (x) 12 BUILD_MAP 0 15 SET_ADD 2 18 JUMP_ABSOLUTE 6 >> 21 RETURN_VALUE From g.brandl at gmx.net Sun Jan 25 16:32:01 2015 From: g.brandl at gmx.net (Georg Brandl) Date: Sun, 25 Jan 2015 16:32:01 +0100 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150125160854.36e785e0@fsol> References: <20150125160854.36e785e0@fsol> Message-ID: On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > On Sat, 24 Jan 2015 21:10:51 -0500 > Neil Girdhar wrote: >> To finish PEP 448, I need to update the grammar for syntax such as >> >> {**x for x in it} > > Is this seriously allowed by the PEP? What does it mean exactly? It appears to go a bit far. Especially since you also would have to allow {*x for x in it} which is a set comprehension, while the other is a dict comprehension :) Georg From chaselton at gmail.com Sun Jan 25 16:32:41 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sun, 25 Jan 2015 09:32:41 -0600 Subject: [Python-Dev] Can Python Be Built Without Distutils In-Reply-To: References: <54C29784.2080908@ubuntu.com> <54C29ED2.2050508@egenix.com> <54C40632.4020301@egenix.com> <20150124232430.49c859ca@fsol> Message-ID: Since (judging from the lack of responses) setup.py can't be removed from the Makefile, I kept troubleshooting.I've managed to get the build to complete and make install runs instead of throwing an undefined reference right off the bat, unfortunately I've run into the following: ImportError: No module named _struct This also happens when make test is run. I;ve checked...the _struct module is there. On Sat, Jan 24, 2015 at 11:22 PM, Gregory P. Smith wrote: > Why doesn't our Makefile supply that flag with the make parallelism level in > the sharedmods step? > > On Sat Jan 24 2015 at 2:25:45 PM Antoine Pitrou wrote: >> >> On Sat, 24 Jan 2015 21:53:06 +0100 >> "M.-A. Lemburg" wrote: >> > >> > BTW: Parallel execution, cross compilation can be added >> > to setup.py. I don't think parallel execution is all >> > that important, >> >> $ ./python setup.py build_ext --help >> [...] >> --parallel (-j) number of parallel build jobs >> >> >> Regards >> >> Antoine. >> >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org > > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chaselton%40gmail.com > From rdmurray at bitdance.com Sun Jan 25 17:32:07 2015 From: rdmurray at bitdance.com (R. David Murray) Date: Sun, 25 Jan 2015 11:32:07 -0500 Subject: [Python-Dev] Why are generated files in the repository? In-Reply-To: References: <1421715205.3228470.216025885.783BAA35@webmail.messagingengine.com> <1422112159.1282007.218271121.1981C99D@webmail.messagingengine.com> Message-ID: <20150125163207.8DCEC250F55@webabinitio.net> On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan wrote: > It's far more developer friendly to aim to have builds from a source > check-out "just work" if we can. That's pretty much where we are today > (getting external dependencies for the optional parts on *nix can still be > a bit fiddly - it may be worth maintaining instructions for at least apt > and yum in the developer guide that cover that) https://docs.python.org/devguide/setup.html#build-dependencies From chaselton at gmail.com Sun Jan 25 20:51:22 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sun, 25 Jan 2015 13:51:22 -0600 Subject: [Python-Dev] Can Python Be Built Without Distutils In-Reply-To: <54C4C0A3.7060701@cavallinux.eu> References: <54C29784.2080908@ubuntu.com> <54C29ED2.2050508@egenix.com> <54C4C0A3.7060701@cavallinux.eu> Message-ID: Thanks...this looks interesting Antonio. I'm not familiar enough with Makefile syntax and creation to know if this can help in my case and (fingers crossed) I believe I've just about solved my original undefined reference to dlopen problem, but I'll be bookmarking it for future reference (and in case I'm wrong about being close to solving my original Android build issues). On Sun, Jan 25, 2015 at 4:08 AM, Antonio Cavallo wrote: > I tried a Makefile based build of python (+ some module) in the past for > Android (and macos): > > https://bitbucket.org/cavallo71/android > > There was no particular problem in dropping autoconfigure+setup.py in the > process: the only real problem was the pgen must be compiled on the host > machine (but that could have changed since). > > In general python was a plain compile and link stuff with not much magic > involved and that is (very) good in my opinion: magic detection tends to > fail, autoconfigure need to "execute" stuff to detect things (reason why is > quite useless in cross-compile mode) etc. > > I would've tried also cmake and qmake builds as well, but simply I didn't > have time to spend on it. > > I hope this helps, > Antonio > > > > Zachary Ware wrote: >> >> On Saturday, January 24, 2015, Brett Cannon > > wrote: >> >> On Fri Jan 23 2015 at 5:45:28 PM Gregory P. Smith > > wrote: >> >> On Fri Jan 23 2015 at 11:20:02 AM M.-A. Lemburg > > wrote: >> >> On 23.01.2015 19:48, Matthias Klose wrote: >> > On 01/23/2015 06:30 PM, Cyd Haselton wrote: >> >> Related to my earlier question regarding building Python >> on Android >> >> and an undefined reference to dlopen error...I have the >> following >> >> question: Is it possible to build and install Python >> without having >> >> to build and install...or use...distutils? >> >> >> >> Some background: >> >> I can build the python interpreter on my device, and I can >> build a >> >> bunch of modules. The problem appears when make reaches >> the part >> >> where setup.py is used to build and import >> modules...specifically when >> >> setup.py attempts to import distutils.core. >> > >> > you can do this using Setup.local. This works for me >> building additional >> > extensions as builtins. It might require some tweaking to >> build everything. >> >> You may want to have a look at the Setup files we're using >> in eGenix PyRun, which uses them to force static builds of the >> various built-in extensions. >> >> Look for these files: >> >> PyRun/Runtime/Setup.PyRun-2.7 >> PyRun/Runtime/Setup.PyRun-3.4 >> >> in the source archives: >> >> http://www.egenix.com/__products/python/PyRun/ >> >> >> > Otoh, I would like to get rid off the setup.py altogether >> (/me ducks ...). >> >> Why ? It's great for finding stuff on your system and >> configuring >> everything without user intervention (well, most of the time >> :-)). >> >> >> Because our setup.py is a nightmare of arbitrary code run in a >> linear fashion with ad-hoc checks for things that are >> unlike how any other project on the planet determines what is >> available on your system. It may have seemed "great" when >> it was created in 2001. It really shows its age now. >> >> It defeats build parallelism and dependency declaration. >> It also prevents cross compilation. >> >> Building an interpreter with a limited standard library on your >> build host so that you can run said interpreter to have >> it drive the remainder of your build is way more self hosting that >> we rightfully need to be for CPython. >> >> >> So are you suggesting to add the build rules to configure and the >> Makefile -- and Windows build file -- in order to drop >> setup.py? >> >> >> Windows already doesn't use setup.py. There are a lot more modules >> built-in on Windows, and others have their own project files; >> distutils isn't used at all. >> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/a.cavallo%40cavallinux.eu > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chaselton%40gmail.com From greg.ewing at canterbury.ac.nz Sun Jan 25 22:56:17 2015 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Mon, 26 Jan 2015 10:56:17 +1300 Subject: [Python-Dev] Disassembly of generated comprehensions In-Reply-To: References: Message-ID: <54C56681.9060607@canterbury.ac.nz> Petr Viktorin wrote: > On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar wrote: > >>How do I disassemble a generated comprehension? >> > Put it in a function, then get it from the function's code's constants. It would be handy if dis had an option to disassemble nested functions like this automatically. -- Greg From ncoghlan at gmail.com Mon Jan 26 00:05:19 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 26 Jan 2015 09:05:19 +1000 Subject: [Python-Dev] Why are generated files in the repository? In-Reply-To: <20150125163207.8DCEC250F55@webabinitio.net> References: <1421715205.3228470.216025885.783BAA35@webmail.messagingengine.com> <1422112159.1282007.218271121.1981C99D@webmail.messagingengine.com> <20150125163207.8DCEC250F55@webabinitio.net> Message-ID: On 26 Jan 2015 02:33, "R. David Murray" wrote: > > On Sun, 25 Jan 2015 14:00:57 +1000, Nick Coghlan wrote: > > It's far more developer friendly to aim to have builds from a source > > check-out "just work" if we can. That's pretty much where we are today > > (getting external dependencies for the optional parts on *nix can still be > > a bit fiddly - it may be worth maintaining instructions for at least apt > > and yum in the developer guide that cover that) > > https://docs.python.org/devguide/setup.html#build-dependencies Heh, as I was writing that I was thinking, "Did we do that already?". I should have gone and checked :) Cheers, Nick. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Sun Jan 25 23:59:42 2015 From: guido at python.org (Guido van Rossum) Date: Sun, 25 Jan 2015 14:59:42 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> Message-ID: On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > On Sat, 24 Jan 2015 21:10:51 -0500 > > Neil Girdhar wrote: > >> To finish PEP 448, I need to update the grammar for syntax such as > >> > >> {**x for x in it} > > > > Is this seriously allowed by the PEP? What does it mean exactly? > > It appears to go a bit far. Especially since you also would have to allow > > {*x for x in it} > > which is a set comprehension, while the other is a dict comprehension :) > That distinction doesn't bother me -- you might as well claim it's confusing that f(*x) passes positional args from x while f(**x) passes keyword args. And the varargs set comprehension is similar to the varargs list comprehension: [*x for x in it] If `it` were a list of three items, this would be the same as [*it[0], *it[1], *it[2]] so the original is a flattening of `it`: [*it[0], *it[1], ...]. (The type of `it` is wider than list of lists -- it could be an iterable of iterables. But the thing is still a flattening.) The set flattening follows from a direct analogy. And `it` doesn't have to be a set of sets, it still just needs to be an iterable of iterables -- it's only the flattened result that's turned into a set. The dict comprehension follows from there -- the input must be an iterable of iterables of (key, value) pairs. I like the example from the PEP, a dict combining globals() and locals(): {**dictionary for dictionary in (globals(), locals())} This could be written as {**globals(), **locals()} but the general case (a variable number of dicts to combine) requires the comprehension. The PEP also supports generator expressions that are flattenings, and again that follows directly from analogy. Interestingly, the non-dict versions can all be written today using a double-nested comprehension, e.g. {**x for x in it} can be written as: {x for x in xs for xs in it} But it's not so straightforward for dict comprehensions -- you'd have to switch to calling dict(): dict(x for x in xs for xs in it) -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ncoghlan at gmail.com Mon Jan 26 00:11:20 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Mon, 26 Jan 2015 09:11:20 +1000 Subject: [Python-Dev] Disassembly of generated comprehensions In-Reply-To: <54C56681.9060607@canterbury.ac.nz> References: <54C56681.9060607@canterbury.ac.nz> Message-ID: On 26 Jan 2015 07:58, "Greg Ewing" wrote: > > Petr Viktorin wrote: >> >> On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar wrote: >> >>> How do I disassemble a generated comprehension? >>> >> Put it in a function, then get it from the function's code's constants. > > > It would be handy if dis had an option to disassemble nested > functions like this automatically. The code for that already exists, but it needs someone with the roundtuits to put together new tests and docs: http://bugs.python.org/issue11822 Cheers, Nick. > > -- > Greg > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Mon Jan 26 01:21:24 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 26 Jan 2015 01:21:24 +0100 Subject: [Python-Dev] Any grammar experts? References: <20150125160854.36e785e0@fsol> Message-ID: <20150126012124.23b6ce31@fsol> On Sun, 25 Jan 2015 14:59:42 -0800 Guido van Rossum wrote: > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > > On Sat, 24 Jan 2015 21:10:51 -0500 > > > Neil Girdhar wrote: > > >> To finish PEP 448, I need to update the grammar for syntax such as > > >> > > >> {**x for x in it} > > > > > > Is this seriously allowed by the PEP? What does it mean exactly? > > > > It appears to go a bit far. Especially since you also would have to allow > > > > {*x for x in it} > > > > which is a set comprehension, while the other is a dict comprehension :) > > > > That distinction doesn't bother me -- you might as well claim it's > confusing that f(*x) passes positional args from x while f(**x) passes > keyword args. > > And the varargs set comprehension is similar to the varargs list > comprehension: > > [*x for x in it] > > If `it` were a list of three items, this would be the same as > > [*it[0], *it[1], *it[2]] I find all this unreadable and difficult to understand. Regards Antoine. From rdmurray at bitdance.com Mon Jan 26 03:31:36 2015 From: rdmurray at bitdance.com (R. David Murray) Date: Sun, 25 Jan 2015 21:31:36 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126012124.23b6ce31@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> Message-ID: <20150126023137.0475C250DAC@webabinitio.net> On Mon, 26 Jan 2015 01:21:24 +0100, Antoine Pitrou wrote: > On Sun, 25 Jan 2015 14:59:42 -0800 > Guido van Rossum wrote: > > On Sun, Jan 25, 2015 at 7:32 AM, Georg Brandl wrote: > > > > > On 01/25/2015 04:08 PM, Antoine Pitrou wrote: > > > > On Sat, 24 Jan 2015 21:10:51 -0500 > > > > Neil Girdhar wrote: > > > >> To finish PEP 448, I need to update the grammar for syntax such as > > > >> > > > >> {**x for x in it} > > > > > > > > Is this seriously allowed by the PEP? What does it mean exactly? > > > > > > It appears to go a bit far. Especially since you also would have to allow > > > > > > {*x for x in it} > > > > > > which is a set comprehension, while the other is a dict comprehension :) > > > > > > > That distinction doesn't bother me -- you might as well claim it's > > confusing that f(*x) passes positional args from x while f(**x) passes > > keyword args. > > > > And the varargs set comprehension is similar to the varargs list > > comprehension: > > > > [*x for x in it] > > > > If `it` were a list of three items, this would be the same as > > > > [*it[0], *it[1], *it[2]] > > I find all this unreadable and difficult to understand. I did too, before reading the PEP. After reading the PEP, it makes perfect sense to me. Nor is the PEP complicated...it's just a matter of wrapping your head around the generalization[*] of what are currently special cases that is going on here. --David [*] The *further* generalization...we've already had, for example, the generalization that allows: a, *b = (1, 3, 4) to work, and that seems very clear to us....now. From barry at python.org Mon Jan 26 15:43:26 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 26 Jan 2015 09:43:26 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126023137.0475C250DAC@webabinitio.net> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> Message-ID: <20150126094326.7ee63001@limelight.wooz.org> On Jan 25, 2015, at 09:31 PM, R. David Murray wrote: >> > > {*x for x in it} >> > > >> > > which is a set comprehension, while the other is a dict comprehension :) >> > > >> > >> > That distinction doesn't bother me -- you might as well claim it's >> > confusing that f(*x) passes positional args from x while f(**x) passes >> > keyword args. >> > >> > And the varargs set comprehension is similar to the varargs list >> > comprehension: >> > >> > [*x for x in it] >> > >> > If `it` were a list of three items, this would be the same as >> > >> > [*it[0], *it[1], *it[2]] >> >> I find all this unreadable and difficult to understand. > >I did too, before reading the PEP. > >After reading the PEP, it makes perfect sense to me. Nor is the PEP >complicated...it's just a matter of wrapping your head around the >generalization[*] of what are currently special cases that is going on >here. It does make sense after reading the PEP but it also reduces the readability and instant understanding of any such code. This is head-scratcher code that I'm sure I'd get asked about from folks who aren't steeped in all the dark corners of Python. I don't know if that's an argument not to adopt the PEP, but it I think it would be a good reason to recommend against using such obscure syntax, unless there's a good reason (and good comments!). Cheers, -Barry From rdmurray at bitdance.com Mon Jan 26 16:46:02 2015 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 26 Jan 2015 10:46:02 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126094326.7ee63001@limelight.wooz.org> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> Message-ID: <20150126154602.BEC80250F10@webabinitio.net> On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw wrote: > On Jan 25, 2015, at 09:31 PM, R. David Murray wrote: > > >> > > {*x for x in it} > >> > > > >> > > which is a set comprehension, while the other is a dict comprehension :) > >> > > > >> > > >> > That distinction doesn't bother me -- you might as well claim it's > >> > confusing that f(*x) passes positional args from x while f(**x) passes > >> > keyword args. > >> > > >> > And the varargs set comprehension is similar to the varargs list > >> > comprehension: > >> > > >> > [*x for x in it] > >> > > >> > If `it` were a list of three items, this would be the same as > >> > > >> > [*it[0], *it[1], *it[2]] > >> > >> I find all this unreadable and difficult to understand. > > > >I did too, before reading the PEP. > > > >After reading the PEP, it makes perfect sense to me. Nor is the PEP > >complicated...it's just a matter of wrapping your head around the > >generalization[*] of what are currently special cases that is going on > >here. > > It does make sense after reading the PEP but it also reduces the readability > and instant understanding of any such code. This is head-scratcher code that > I'm sure I'd get asked about from folks who aren't steeped in all the dark > corners of Python. I don't know if that's an argument not to adopt the PEP, > but it I think it would be a good reason to recommend against using such > obscure syntax, unless there's a good reason (and good comments!). But it is only obscure because we are not used to it yet. It is a logical extension of Python's existing conventions once you think about it. It will become "obvious" quickly, IMO. --David From greg at krypto.org Mon Jan 26 18:24:31 2015 From: greg at krypto.org (Gregory P. Smith) Date: Mon, 26 Jan 2015 17:24:31 +0000 Subject: [Python-Dev] is a new buildbot gps-debian-profile-opt possible? References: Message-ID: I want this buildbot to run "make profile-opt" instead of "make all" and it'd be best if it could _not_ have --with-pydebug on the ./configure command line. I've got a small VM at the moment with one CPU and 600mb ram so just give it a make -j2 at most to start with. If that is possible, please assign the new buildbot name and password for me and i'll get it up and running. motivation for such a buildbot: https://bugs.python.org/issue22904 and any potential similar issues. fwiw, the major linux distros ship with profile-opt interpreter builds as they are significantly faster. thanks, -gps -------------- next part -------------- An HTML attachment was scrubbed... URL: From solipsis at pitrou.net Mon Jan 26 19:12:09 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 26 Jan 2015 19:12:09 +0100 Subject: [Python-Dev] Any grammar experts? References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> Message-ID: <20150126191209.11233ab7@fsol> On Mon, 26 Jan 2015 10:46:02 -0500 "R. David Murray" wrote: > On Mon, 26 Jan 2015 09:43:26 -0500, Barry Warsaw wrote: > > On Jan 25, 2015, at 09:31 PM, R. David Murray wrote: > > > > >> > > {*x for x in it} > > >> > > > > >> > > which is a set comprehension, while the other is a dict comprehension :) > > >> > > > > >> > > > >> > That distinction doesn't bother me -- you might as well claim it's > > >> > confusing that f(*x) passes positional args from x while f(**x) passes > > >> > keyword args. > > >> > > > >> > And the varargs set comprehension is similar to the varargs list > > >> > comprehension: > > >> > > > >> > [*x for x in it] > > >> > > > >> > If `it` were a list of three items, this would be the same as > > >> > > > >> > [*it[0], *it[1], *it[2]] > > >> > > >> I find all this unreadable and difficult to understand. > > > > > >I did too, before reading the PEP. > > > > > >After reading the PEP, it makes perfect sense to me. Nor is the PEP > > >complicated...it's just a matter of wrapping your head around the > > >generalization[*] of what are currently special cases that is going on > > >here. > > > > It does make sense after reading the PEP but it also reduces the readability > > and instant understanding of any such code. This is head-scratcher code that > > I'm sure I'd get asked about from folks who aren't steeped in all the dark > > corners of Python. I don't know if that's an argument not to adopt the PEP, > > but it I think it would be a good reason to recommend against using such > > obscure syntax, unless there's a good reason (and good comments!). > > But it is only obscure because we are not used to it yet. It is a > logical extension of Python's existing conventions once you think about > it. It will become "obvious" quickly, IMO. I have to agree with Barry. While the following is obvious even without having ever used it: a, b, *c = range(5) the following makes me scratch my head and I can't seem to guess what the *intent* is - which is very problematic when e.g. reviewing code: [*x for x in it] {**x for x in it} (and other similar things) I also think the multiple-starargs function calls are completely overboard: f(**someargs, **someotherargs) (I might add I've never felt any need for those) These generalizations look to me like a case of consistency taken too far. When some construct needs commenting to be understandable, then probably that construct shouldn't exist at all. (yes, I should have reacted earlier. I hadn't realized the PEP went that far. It seemed short and simple so I didn't look carefully :-)) By the way, when reading https://www.python.org/dev/peps/pep-0448/, I can't find a reference to the final pronouncement. Regards Antoine. From skip.montanaro at gmail.com Mon Jan 26 19:25:10 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Mon, 26 Jan 2015 12:25:10 -0600 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126191209.11233ab7@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> Message-ID: On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou wrote: > I also think the multiple-starargs function calls are completely > overboard: > > f(**someargs, **someotherargs) > > (I might add I've never felt any need for those) This makes sense to me, but I wonder how you resolve the case of overlapping keys. I will note that pylint complains about any use of *args or **kwds (calling it "magic"), which seems a bit overboard to me. There's nothing magic in the current implementation as far as I can see. I wonder if it makes sense for pylint to allow simple use (basically, the status quo) to fly by silently, but start to chirp when people use the facility in all its baroque glory as enabled by the PEP. Skip From p.f.moore at gmail.com Mon Jan 26 19:40:12 2015 From: p.f.moore at gmail.com (Paul Moore) Date: Mon, 26 Jan 2015 18:40:12 +0000 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126191209.11233ab7@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> Message-ID: On 26 January 2015 at 18:12, Antoine Pitrou wrote: > I have to agree with Barry. While the following is obvious even without > having ever used it: > > a, b, *c = range(5) > > the following makes me scratch my head and I can't seem to guess what > the *intent* is - which is very problematic when e.g. reviewing code: > > [*x for x in it] > {**x for x in it} > > (and other similar things) > > I also think the multiple-starargs function calls are completely > overboard: > > f(**someargs, **someotherargs) > > (I might add I've never felt any need for those) These cases made little sense to me when I first saw them here, but a quick read of the PEP made them feel reasonably straightforward - *x is essentially splicing in a list, and a sequence of **x is a sort of "if you don't find it here, look here" fallback mechanism. Also, real examples would presumably have clearer variable names, and maybe even an explanatory comment. And if they don't, they should do (and a code review that said "this is confusing, add a comment" would seem entirely appropriate to me). There *are* some nastily non-intuitive corner cases (for example, if from_env={'a':12} and from_config={'a':13}, I don't have any sort of intuition as to what a would be in f(**from_env, **from_config). I'd go with 12 because the PEP links multiple **-unpackings with collections.ChainMap, but I wouldn't dare rely on that guess). My feeling is that the PEP is essentially fine, but the "Disadvantages" section needs expansion to note (in a reasonable amount of detail) that it's possible to write very obfuscated code with these constructs. It should also call out the corner cases and note that the behaviour, although following from the rules, isn't obvious. Personally, I don't think the resulting disadvantages are so bad that the PEP needs to be rejected, it's just a matter of being open about the potential for unclear code. Paul From solipsis at pitrou.net Mon Jan 26 19:55:52 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 26 Jan 2015 19:55:52 +0100 Subject: [Python-Dev] is a new buildbot gps-debian-profile-opt possible? References: Message-ID: <20150126195552.09642df2@fsol> Of course. I hadn't had time to answer your private e-mail but will do so soon :-) Regards Antoine. On Mon, 26 Jan 2015 17:24:31 +0000 "Gregory P. Smith" wrote: > I want this buildbot to run "make profile-opt" instead of "make all" and > it'd be best if it could _not_ have --with-pydebug on the ./configure > command line. > > I've got a small VM at the moment with one CPU and 600mb ram so just give > it a make -j2 at most to start with. > > If that is possible, please assign the new buildbot name and password for > me and i'll get it up and running. > > motivation for such a buildbot: https://bugs.python.org/issue22904 and any > potential similar issues. fwiw, the major linux distros ship with > profile-opt interpreter builds as they are significantly faster. > > thanks, > -gps > From ethan at stoneleaf.us Mon Jan 26 19:55:58 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 10:55:58 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> Message-ID: <54C68DBE.2020404@stoneleaf.us> On 01/26/2015 10:40 AM, Paul Moore wrote: > There *are* some nastily non-intuitive corner cases (for example, if > from_env={'a':12} and from_config={'a':13}, I don't have any sort of > intuition as to what a would be in f(**from_env, **from_config). I'd > go with 12 because the PEP links multiple **-unpackings with > collections.ChainMap, but I wouldn't dare rely on that guess). In the your example from_env = {'a': 12} from_config = {'a': 13} f(**from_env, **from_config) I would think 'a' should be 13, as from_config is processed /after/ from_env. So which is it? -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From skip.montanaro at gmail.com Mon Jan 26 20:04:38 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Mon, 26 Jan 2015 13:04:38 -0600 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <54C68DBE.2020404@stoneleaf.us> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> Message-ID: On Mon, Jan 26, 2015 at 12:55 PM, Ethan Furman wrote: > So which is it? Precisely... S From ethan at stoneleaf.us Mon Jan 26 20:04:25 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 11:04:25 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <54C68DBE.2020404@stoneleaf.us> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> Message-ID: <54C68FB9.602@stoneleaf.us> On 01/26/2015 10:55 AM, Ethan Furman wrote: > On 01/26/2015 10:40 AM, Paul Moore wrote: > >> There *are* some nastily non-intuitive corner cases (for example, if >> from_env={'a':12} and from_config={'a':13}, I don't have any sort of >> intuition as to what a would be in f(**from_env, **from_config). I'd >> go with 12 because the PEP links multiple **-unpackings with >> collections.ChainMap, but I wouldn't dare rely on that guess). > > In the your example > > from_env = {'a': 12} > from_config = {'a': 13} > > f(**from_env, **from_config) > > I would think 'a' should be 13, as from_config is processed /after/ from_env. > > So which is it? Going to the PEP: kwargs = dict(kw_arguments) kwargs.update(more_arguments) function(**kwargs) or, if you know to do so: from collections import ChainMap function(**ChainMap(more_arguments, arguments)) I see the arguments to ChainMap are reversed (more_arguments is first), so in Paul's example 'a' would be 13. -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From barry at python.org Mon Jan 26 20:24:59 2015 From: barry at python.org (Barry Warsaw) Date: Mon, 26 Jan 2015 14:24:59 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <54C68DBE.2020404@stoneleaf.us> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> Message-ID: <20150126142459.74c4d7d4@limelight.wooz.org> On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: >In the your example > > from_env = {'a': 12} > from_config = {'a': 13} > > f(**from_env, **from_config) > >I would think 'a' should be 13, as from_config is processed /after/ from_env. > >So which is it? In the face of ambiguity, refuse the temptation to guess. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From ethan at stoneleaf.us Mon Jan 26 20:29:20 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 11:29:20 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126142459.74c4d7d4@limelight.wooz.org> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> Message-ID: <54C69590.7070409@stoneleaf.us> On 01/26/2015 11:24 AM, Barry Warsaw wrote: > On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: > >> In the your example >> >> from_env = {'a': 12} >> from_config = {'a': 13} >> >> f(**from_env, **from_config) >> >> I would think 'a' should be 13, as from_config is processed /after/ from_env. >> >> So which is it? > > In the face of ambiguity, refuse the temptation to guess. Lots of things are ambiguous until one learns the rules. ;) -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From demianbrecht at gmail.com Mon Jan 26 20:49:22 2015 From: demianbrecht at gmail.com (Demian Brecht) Date: Mon, 26 Jan 2015 11:49:22 -0800 Subject: [Python-Dev] Overriding stdlib http package In-Reply-To: References: <54B69A17.9060209@gmail.com> <54B6CC99.2040501@gmail.com> <54B6D8D3.4090706@gmail.com> Message-ID: <54C69A42.6010700@gmail.com> On 2015-01-24 7:17 AM, Donald Stufft wrote: > It?s not just power users that it?s good for, it makes it harder for > even beginners to use things like backports of modules. What about cases where new module versions are put in as dependencies of other packages and they stomp standard library packages unbeknownst to the user installing the higher level package? For example, let's say packageB overrides stdlib's packageA. packageC requires packageB, which stomps packageA at import time. Now, author of packageD requires packageC but is unaware of the fact that packageB overrides packageA, but heavily uses packageA directly and expects the stdlib behavior, not the modified behavior in packageB. (Hope I got the hierarchy right in that description ;)) This would likely cause unexpected behavior and I can only assume that it would likely be quite difficult to track down, even for a power user. The same logic applies to unrelated stdlib modules that depend on the stdlib behavior of packageA as Brett pointed out. As someone who's recently faced the problem, while making it easier would have been immediately beneficial to me as the module author, I can understand the reasoning behind making this a difficult thing to do. I /do/ think that it might be worthwhile to invest some time in making it easier to do while still satisfying the safety of other packages, but I would venture to say it would definitely be non-trivial. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From chaselton at gmail.com Mon Jan 26 19:49:01 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Mon, 26 Jan 2015 12:49:01 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? Message-ID: Hello, I've finally managed to build a (somewhat) working Python port for the Android tablet I'm using. Unfortunately, as I quickly found out, Python's built-in help function requires tkinter, which requires tcl/tk. I did download the sources for tcl/tk and built tcl, but found out that tk requires XWindows libraries and includes. Long story short: Is there an alternative documentation system (i.e. epydoc) that does not have tkinter dependencies? If so, is there a parameter or env variable that would allow me to use it instead of pydoc? Thanks in advance, Cyd From encukou at gmail.com Mon Jan 26 20:39:00 2015 From: encukou at gmail.com (Petr Viktorin) Date: Mon, 26 Jan 2015 20:39:00 +0100 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <54C69590.7070409@stoneleaf.us> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> Message-ID: On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman wrote: > On 01/26/2015 11:24 AM, Barry Warsaw wrote: >> On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: >> >>> In the your example >>> >>> from_env = {'a': 12} >>> from_config = {'a': 13} >>> >>> f(**from_env, **from_config) >>> >>> I would think 'a' should be 13, as from_config is processed /after/ from_env. >>> >>> So which is it? >> >> In the face of ambiguity, refuse the temptation to guess. > > Lots of things are ambiguous until one learns the rules. ;) I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent to `f(a=12, **{'a':13})` ? iow, raise TypeError. From ethan at stoneleaf.us Mon Jan 26 21:06:26 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 12:06:26 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> Message-ID: <54C69E42.4020905@stoneleaf.us> On 01/26/2015 11:39 AM, Petr Viktorin wrote: > On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman wrote: >> On 01/26/2015 11:24 AM, Barry Warsaw wrote: >>> On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: >>> >>>> In the your example >>>> >>>> from_env = {'a': 12} >>>> from_config = {'a': 13} >>>> >>>> f(**from_env, **from_config) >>>> >>>> I would think 'a' should be 13, as from_config is processed /after/ from_env. >>>> >>>> So which is it? >>> >>> In the face of ambiguity, refuse the temptation to guess. >> >> Lots of things are ambiguous until one learns the rules. ;) > > I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent > to `f(a=12, **{'a':13})` ? iow, raise TypeError. It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that the same key could be in more than one of the dictionaries then you still have to do the dict.update(another_dict) dance. -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From solipsis at pitrou.net Mon Jan 26 21:09:44 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 26 Jan 2015 21:09:44 +0100 Subject: [Python-Dev] Any grammar experts? References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> Message-ID: <20150126210944.425ccad3@fsol> On Mon, 26 Jan 2015 12:06:26 -0800 Ethan Furman wrote: > It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that > the same key could be in more than one of the dictionaries then you still have to do the > > dict.update(another_dict) So what? Is the situation where chaining is desirable common enough? Not every new feature warrants a syntax addition - especially when it raises eyebrows as here, and ends up being as obscure as Perl code. Regards Antoine. From rymg19 at gmail.com Mon Jan 26 21:08:59 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Mon, 26 Jan 2015 14:08:59 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: Looking at pydoc.py, it looks like the Tk is purely optional...and isn't called from the interpreter. (I'm not a core dev, though, so take that with a grain of salt.) However, can't you just strip out the gui function and the one place in the file where it's called? Again, not a main Python developer, so don't take this too seriously! On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: > Hello, > I've finally managed to build a (somewhat) working Python port for the > Android tablet I'm using. Unfortunately, as I quickly found out, > Python's built-in help function requires tkinter, which requires > tcl/tk. > > I did download the sources for tcl/tk and built tcl, but found out > that tk requires XWindows libraries and includes. > > Long story short: Is there an alternative documentation system (i.e. > epydoc) that does not have tkinter dependencies? If so, is there a > parameter or env variable that would allow me to use it instead of > pydoc? > > Thanks in advance, > Cyd > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tseaver at palladion.com Mon Jan 26 21:17:27 2015 From: tseaver at palladion.com (Tres Seaver) Date: Mon, 26 Jan 2015 15:17:27 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126094326.7ee63001@limelight.wooz.org> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/26/2015 09:43 AM, Barry Warsaw wrote: > This is head-scratcher code that I'm sure I'd get asked about from > folks who aren't steeped in all the dark corners of Python. I don't > know if that's an argument not to adopt the PEP, but it I think it > would be a good reason to recommend against using such obscure syntax, > unless there's a good reason Heh, 2003 called, and they want their "list incomprehension" debate back. ;) Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlTGoNcACgkQ+gerLs4ltQ4AWQCfQ/zjosbaC6YcPItzmxZer/oW f/cAoLwXzzfHV2LhT4AZD/KS31TkKJyI =Oxqm -----END PGP SIGNATURE----- From ethan at stoneleaf.us Mon Jan 26 21:22:20 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 12:22:20 -0800 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126210944.425ccad3@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> <20150126210944.425ccad3@fsol> Message-ID: <54C6A1FC.7090307@stoneleaf.us> On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 12:06:26 -0800 > Ethan Furman wrote: >> It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that >> the same key could be in more than one of the dictionaries then you still have to do the >> >> dict.update(another_dict) > > So what? Is the situation where chaining is desirable common enough? Common enough to not break it, yes. > Not every new feature warrants a syntax addition - especially when it > raises eyebrows as here, and ends up being as obscure as Perl code. Not sure what you mean here -- the new feature is a syntax addition (or more appropriately a generalization of existing syntax). -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From ethan at stoneleaf.us Mon Jan 26 21:25:19 2015 From: ethan at stoneleaf.us (Ethan Furman) Date: Mon, 26 Jan 2015 12:25:19 -0800 Subject: [Python-Dev] Python bug tracker & Roundup Message-ID: <54C6A2AF.60301@stoneleaf.us> Do we have our own mailing list for Roundup? I'm trying to fix the Activity Date search bug (only returns issues where the *last* activity was on a date, not *any* activity on a date). -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From skip.montanaro at gmail.com Mon Jan 26 21:26:52 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Mon, 26 Jan 2015 14:26:52 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: > Unfortunately, as I quickly found out, > Python's built-in help function requires tkinter, which requires > tcl/tk. I'm a little confused. Are you using some sort of freeze system which is deciding Tkinter is required? I use help() all the time from the interpreter prompt and never get a GUI. IMO you should be able to strip out the gui() function (or even just comment out the Tkinter import). Skip From berker.peksag at gmail.com Mon Jan 26 21:30:21 2015 From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=) Date: Mon, 26 Jan 2015 22:30:21 +0200 Subject: [Python-Dev] Python bug tracker & Roundup In-Reply-To: <54C6A2AF.60301@stoneleaf.us> References: <54C6A2AF.60301@stoneleaf.us> Message-ID: On Mon, Jan 26, 2015 at 10:25 PM, Ethan Furman wrote: > Do we have our own mailing list for Roundup? Hi, Yes: https://mail.python.org/mailman/listinfo/tracker-discuss There is also a tracker for bugs.p.o: http://psf.upfronthosting.co.za/roundup/meta/ --Berker From zachary.ware+pydev at gmail.com Mon Jan 26 21:25:57 2015 From: zachary.ware+pydev at gmail.com (Zachary Ware) Date: Mon, 26 Jan 2015 14:25:57 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: > Hello, > I've finally managed to build a (somewhat) working Python port for the > Android tablet I'm using. Unfortunately, as I quickly found out, > Python's built-in help function requires tkinter, which requires > tcl/tk. What version of Python are you building, and how did you call help that it seems to want to use tkinter? The pydoc GUI was removed from the 3.x series long ago, and should only be activated in 2.7 if you call it as 'pydoc -g ...' from the command line (or use pydoc.gui() directly). -- Zach From g.brandl at gmx.net Mon Jan 26 21:32:33 2015 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 26 Jan 2015 21:32:33 +0100 Subject: [Python-Dev] Python bug tracker & Roundup In-Reply-To: <54C6A2AF.60301@stoneleaf.us> References: <54C6A2AF.60301@stoneleaf.us> Message-ID: On 01/26/2015 09:25 PM, Ethan Furman wrote: > Do we have our own mailing list for Roundup? > > I'm trying to fix the Activity Date search bug (only returns issues where the > *last* activity was on a date, not *any* activity on a date). That would be tracker-discuss. Georg From g.brandl at gmx.net Mon Jan 26 21:36:29 2015 From: g.brandl at gmx.net (Georg Brandl) Date: Mon, 26 Jan 2015 21:36:29 +0100 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> Message-ID: On 01/26/2015 07:25 PM, Skip Montanaro wrote: > On Mon, Jan 26, 2015 at 12:12 PM, Antoine Pitrou wrote: >> I also think the multiple-starargs function calls are completely >> overboard: >> >> f(**someargs, **someotherargs) >> >> (I might add I've never felt any need for those) > > This makes sense to me, but I wonder how you resolve the case of > overlapping keys. > > I will note that pylint complains about any use of *args or **kwds > (calling it "magic"), which seems a bit overboard to me. There's > nothing magic in the current implementation as far as I can see. Yeah, that's one of the sillier on-by-default warnings that I always disable immediately. Georg From storchaka at gmail.com Mon Jan 26 21:47:16 2015 From: storchaka at gmail.com (Serhiy Storchaka) Date: Mon, 26 Jan 2015 22:47:16 +0200 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150125160854.36e785e0@fsol> References: <20150125160854.36e785e0@fsol> Message-ID: On 25.01.15 17:08, Antoine Pitrou wrote: > On Sat, 24 Jan 2015 21:10:51 -0500 > Neil Girdhar wrote: >> To finish PEP 448, I need to update the grammar for syntax such as >> {**x for x in it} > Is this seriously allowed by the PEP? What does it mean exactly? I would understand this as {k: v for x in it for k, v in x.items()} From storchaka at gmail.com Mon Jan 26 21:50:08 2015 From: storchaka at gmail.com (Serhiy Storchaka) Date: Mon, 26 Jan 2015 22:50:08 +0200 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> Message-ID: On 26.01.15 00:59, Guido van Rossum wrote: > Interestingly, the non-dict versions can all be written today using a > double-nested comprehension, e.g. {**x for x in it} can be written as: > > {x for x in xs for xs in it} {x for xs in it for x in xs} > But it's not so straightforward for dict comprehensions -- you'd have to > switch to calling dict(): > > dict(x for x in xs for xs in it) {k: v for xs in it for k, v in xs.items()} So actually this is just a syntax sugar. From solipsis at pitrou.net Mon Jan 26 22:05:44 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 26 Jan 2015 22:05:44 +0100 Subject: [Python-Dev] Any grammar experts? References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> <20150126210944.425ccad3@fsol> <54C6A1FC.7090307@stoneleaf.us> Message-ID: <20150126220544.4c069c78@fsol> On Mon, 26 Jan 2015 12:22:20 -0800 Ethan Furman wrote: > On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > > On Mon, 26 Jan 2015 12:06:26 -0800 > > Ethan Furman wrote: > >> It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that > >> the same key could be in more than one of the dictionaries then you still have to do the > >> > >> dict.update(another_dict) > > > > So what? Is the situation where chaining is desirable common enough? > > Common enough to not break it, yes. Really? What are the use cases? > > Not every new feature warrants a syntax addition - especially when it > > raises eyebrows as here, and ends up being as obscure as Perl code. > > Not sure what you mean here -- the new feature is a syntax addition That's what I said. From rdmurray at bitdance.com Mon Jan 26 22:28:24 2015 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 26 Jan 2015 16:28:24 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150126220544.4c069c78@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> <20150126210944.425ccad3@fsol> <54C6A1FC.7090307@stoneleaf.us> <20150126220544.4c069c78@fsol> Message-ID: <20150126212824.E7EF5250EE9@webabinitio.net> On Mon, 26 Jan 2015 22:05:44 +0100, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 12:22:20 -0800 > Ethan Furman wrote: > > On 01/26/2015 12:09 PM, Antoine Pitrou wrote: > > > On Mon, 26 Jan 2015 12:06:26 -0800 > > > Ethan Furman wrote: > > >> It destroy's the chaining value and pretty much makes the improvement not an improvement. If there's a possibility that > > >> the same key could be in more than one of the dictionaries then you still have to do the > > >> > > >> dict.update(another_dict) > > > > > > So what? Is the situation where chaining is desirable common enough? > > > > Common enough to not break it, yes. > > Really? What are the use cases? My use case is a configuration method that takes keyword parameters. In tests I want to specify a bunch of default values for the configuration, but I want individual test methods to be able to override those values. So I have a bunch of code that does the equivalent of: from test.support import default_config [...] def _prep(self, config_overrides): config = default.config.copy() config.update(config_overrides) my_config_object.load(**config) .... With the current proposal I could instead do: def _prep(self, config_overrides): my_config_object.load(**default_config, **config_overrides) I suspect I have run into situations like this elsewhere as well, but this is the one from one of my current projects. That said, I must admit to being a bit ambivalent about this, since we otherwise are careful to disallow duplicate argument names. So, instead we could write: my_config_object.load(**{**default_config, **config_overrides}) since dict literals *do* allow duplicate keys. --David From solipsis at pitrou.net Tue Jan 27 00:07:08 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Tue, 27 Jan 2015 00:07:08 +0100 Subject: [Python-Dev] Any grammar experts? References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> <20150126210944.425ccad3@fsol> <54C6A1FC.7090307@stoneleaf.us> <20150126220544.4c069c78@fsol> <20150126212824.E7EF5250EE9@webabinitio.net> Message-ID: <20150127000708.3cbccb39@fsol> On Mon, 26 Jan 2015 16:28:24 -0500 "R. David Murray" wrote: > > My use case is a configuration method that takes keyword parameters. > In tests I want to specify a bunch of default values for the > configuration, but I want individual test methods to be able > to override those values. So I have a bunch of code that does > the equivalent of: > > from test.support import default_config > [...] > def _prep(self, config_overrides): > config = default.config.copy() > config.update(config_overrides) > my_config_object.load(**config) > .... > > With the current proposal I could instead do: > > def _prep(self, config_overrides): > my_config_object.load(**default_config, **config_overrides) It sounds like the _prep() method exists once in your code base, this isn't an idiom you are duplicating everywhere. The incentive for a syntactic shortcut looks pretty thin. Regards Antoine. From python at mrabarnett.plus.com Tue Jan 27 00:24:21 2015 From: python at mrabarnett.plus.com (MRAB) Date: Mon, 26 Jan 2015 23:24:21 +0000 Subject: [Python-Dev] Any grammar experts? In-Reply-To: References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> Message-ID: <54C6CCA5.7010108@mrabarnett.plus.com> On 2015-01-26 19:39, Petr Viktorin wrote: > On Mon, Jan 26, 2015 at 8:29 PM, Ethan Furman wrote: >> On 01/26/2015 11:24 AM, Barry Warsaw wrote: >>> On Jan 26, 2015, at 10:55 AM, Ethan Furman wrote: >>> >>>> In the your example >>>> >>>> from_env = {'a': 12} >>>> from_config = {'a': 13} >>>> >>>> f(**from_env, **from_config) >>>> >>>> I would think 'a' should be 13, as from_config is processed /after/ from_env. >>>> >>>> So which is it? >>> >>> In the face of ambiguity, refuse the temptation to guess. >> >> Lots of things are ambiguous until one learns the rules. ;) > > I don't see why `f(**{'a': 12}, **{'a': 13})` should not be equivalent > to `f(a=12, **{'a':13})` ? iow, raise TypeError. > One the one hand we have: >>> foo(a=12, **{'a': 13}) Traceback (most recent call last): File " ", line 1, in TypeError: foo() got multiple values for keyword argument 'a' and on the other hand we have: >>> foo(a=12, a=13) File " ", line 1 SyntaxError: keyword argument repeated (Should this be a SyntaxError?) But we also have: >>> {'a': 12, 'a': 13} {'a': 13} So, what should: >>> f(**from_env, **from_config) do if there are common keys? Raise an exception? Behave like dict.update? Behave like ChainMap? From rdmurray at bitdance.com Tue Jan 27 00:32:49 2015 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 26 Jan 2015 18:32:49 -0500 Subject: [Python-Dev] Any grammar experts? In-Reply-To: <20150127000708.3cbccb39@fsol> References: <20150125160854.36e785e0@fsol> <20150126012124.23b6ce31@fsol> <20150126023137.0475C250DAC@webabinitio.net> <20150126094326.7ee63001@limelight.wooz.org> <20150126154602.BEC80250F10@webabinitio.net> <20150126191209.11233ab7@fsol> <54C68DBE.2020404@stoneleaf.us> <20150126142459.74c4d7d4@limelight.wooz.org> <54C69590.7070409@stoneleaf.us> <54C69E42.4020905@stoneleaf.us> <20150126210944.425ccad3@fsol> <54C6A1FC.7090307@stoneleaf.us> <20150126220544.4c069c78@fsol> <20150126212824.E7EF5250EE9@webabinitio.net> <20150127000708.3cbccb39@fsol> Message-ID: <20150126233249.79672250EEE@webabinitio.net> On Tue, 27 Jan 2015 00:07:08 +0100, Antoine Pitrou wrote: > On Mon, 26 Jan 2015 16:28:24 -0500 > "R. David Murray" wrote: > > > > My use case is a configuration method that takes keyword parameters. > > In tests I want to specify a bunch of default values for the > > configuration, but I want individual test methods to be able > > to override those values. So I have a bunch of code that does > > the equivalent of: > > > > from test.support import default_config > > [...] > > def _prep(self, config_overrides): > > config = default.config.copy() > > config.update(config_overrides) > > my_config_object.load(**config) > > .... > > > > With the current proposal I could instead do: > > > > def _prep(self, config_overrides): > > my_config_object.load(**default_config, **config_overrides) > > It sounds like the _prep() method exists once in your code base, this > isn't an idiom you are duplicating everywhere. The incentive for a > syntactic shortcut looks pretty thin. Something similar exists between five and ten times (I didn't go in and count) in my current code base, in various specific forms for different test classes. --David From skip.montanaro at gmail.com Tue Jan 27 13:52:44 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Tue, 27 Jan 2015 06:52:44 -0600 Subject: [Python-Dev] Undefined reference to dlopen (was: Pydoc Replacement for Python's help()?) Message-ID: On Tue, Jan 27, 2015 at 6:31 AM, Cyd Haselton wrote: > Additionally it appears as though some modules were not built with the > correct links to -lc -ldl, even though I added them as dependencies in > Setup and setup.py, as well as in the appropriate env variables. > Importing string, tokenize, operator, inspect...and probably others I > haven't tested...throw the 'undefined reference to dlopen' error. Is this another topic? If so, please start another thread. People glancing at subjects won't recognize that you're now tackling a different problem. The modules you mention here (as well as pydoc) are all pure Python modules. I don't think any of them would have directly triggered a dlopen error. Do you have a traceback? Skip From chaselton at gmail.com Tue Jan 27 13:17:31 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 06:17:31 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Mon, Jan 26, 2015 at 2:25 PM, Zachary Ware wrote: > On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: >> Hello, >> I've finally managed to build a (somewhat) working Python port for the >> Android tablet I'm using. Unfortunately, as I quickly found out, >> Python's built-in help function requires tkinter, which requires >> tcl/tk. > > What version of Python are you building, and how did you call help > that it seems to want to use tkinter? The pydoc GUI was removed from > the 3.x series long ago, and should only be activated in 2.7 if you > call it as 'pydoc -g ...' from the command line (or use pydoc.gui() > directly). > > -- > Zach I'm using version 2.7.8. I'm calling help() from within the python interpreter. From chaselton at gmail.com Tue Jan 27 13:31:44 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 06:31:44 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Mon, Jan 26, 2015 at 2:26 PM, Skip Montanaro wrote: > On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: >> Unfortunately, as I quickly found out, >> Python's built-in help function requires tkinter, which requires >> tcl/tk. > > I'm a little confused. Are you using some sort of freeze system which > is deciding Tkinter is required? I use help() all the time from the > interpreter prompt and never get a GUI. IMO you should be able to > strip out the gui() function (or even just comment out the Tkinter > import). > > Skip I'm not using a freeze system, just the python I built from sources. I may have misread the pydoc and help() documentation online. Additionally it appears as though some modules were not built with the correct links to -lc -ldl, even though I added them as dependencies in Setup and setup.py, as well as in the appropriate env variables. Importing string, tokenize, operator, inspect...and probably others I haven't tested...throw the 'undefined reference to dlopen' error. Looks like I'll need to run make distclean and start over. Is there documentation on which modules are built where and how and with which libraries they are linked? From chaselton at gmail.com Tue Jan 27 13:46:38 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 06:46:38 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Tue, Jan 27, 2015 at 6:31 AM, Cyd Haselton wrote: > On Mon, Jan 26, 2015 at 2:26 PM, Skip Montanaro > wrote: >> On Mon, Jan 26, 2015 at 12:49 PM, Cyd Haselton wrote: >>> Unfortunately, as I quickly found out, >>> Python's built-in help function requires tkinter, which requires >>> tcl/tk. >> >> I'm a little confused. Are you using some sort of freeze system which >> is deciding Tkinter is required? I use help() all the time from the >> interpreter prompt and never get a GUI. IMO you should be able to >> strip out the gui() function (or even just comment out the Tkinter >> import). >> >> Skip > > I'm not using a freeze system, just the python I built from sources. I > may have misread the pydoc and help() documentation online. > > Additionally it appears as though some modules were not built with the > correct links to -lc -ldl, even though I added them as dependencies in > Setup and setup.py, as well as in the appropriate env variables. > Importing string, tokenize, operator, inspect...and probably others I > haven't tested...throw the 'undefined reference to dlopen' error. > > Looks like I'll need to run make distclean and start over. Is there > documentation on which modules are built where and how and with which > libraries they are linked? A quick FYI: The decision to build 2.7.8 (instead of 3.x) on Android was made after reading this article: https://wiki.python.org/moin/Python2orPython3 From skip.montanaro at gmail.com Tue Jan 27 16:07:35 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Tue, 27 Jan 2015 09:07:35 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Tue, Jan 27, 2015 at 6:46 AM, Cyd Haselton wrote: > A quick FYI: The decision to build 2.7.8 (instead of 3.x) on Android > was made after reading this article: > https://wiki.python.org/moin/Python2orPython3 What in that document convinced you to port to Python 2 instead of Python 3? That page is intended for people deciding which version of the language to use for their work. I would think as someone trying to port to a new platform your criteria would be different. Also, note that the above page was last updated in April 2014. Look at the info for that page: https://wiki.python.org/moin/Python2orPython3?action=info and you'll see there was probably nothing of substance added to that page in over a year. Right at the very top of that page, I read: Short version: Python 2.x is legacy, Python 3.x is the present and future of the language I would think that would be enough to convince you to use Python 3.x as your starting point. I say this as someone who, in his day-to-day work uses Python 2.7 exclusively, doesn't expect his employer to ever convert to Python 3, and has never done much more with Python 3 than build it. With all that, if I was going to attempt a port of Python to a new platform, I would still choose to port Python 3. Skip From chaselton at gmail.com Tue Jan 27 16:56:53 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 09:56:53 -0600 Subject: [Python-Dev] Undefined reference to dlopen (was: Pydoc Replacement for Python's help()?) In-Reply-To: References: Message-ID: On Tue, Jan 27, 2015 at 6:52 AM, Skip Montanaro wrote: > On Tue, Jan 27, 2015 at 6:31 AM, Cyd Haselton wrote: >> Additionally it appears as though some modules were not built with the >> correct links to -lc -ldl, even though I added them as dependencies in >> Setup and setup.py, as well as in the appropriate env variables. >> Importing string, tokenize, operator, inspect...and probably others I >> haven't tested...throw the 'undefined reference to dlopen' error. > > Is this another topic? If so, please start another thread. People > glancing at subjects > won't recognize that you're now tackling a different problem. > > The modules you mention here (as well as pydoc) are all pure Python modules. > I don't think any of them would have directly triggered a dlopen error. Do you > have a traceback? > > Skip Apologies for the confusion; the above was not intended to be another topic but an explanation of why the help() module failed in my port and why I believe I'll need to start over. Basically...between my original email and the one above, I managed to review the pydoc.py code, test the imports in said code and discover ones (not tkinter) that were causing errors. From chaselton at gmail.com Tue Jan 27 17:04:45 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 10:04:45 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: On Tue, Jan 27, 2015 at 9:07 AM, Skip Montanaro wrote: > On Tue, Jan 27, 2015 at 6:46 AM, Cyd Haselton wrote: >> A quick FYI: The decision to build 2.7.8 (instead of 3.x) on Android >> was made after reading this article: >> https://wiki.python.org/moin/Python2orPython3 > > What in that document convinced you to port to Python 2 instead of > Python 3? Among other things, the points immediately following this part: However, there are some key issues that may require you to use Python 2 rather than Python 3. That page is intended for people deciding which version of > the language to use for their work. I would think as someone trying to > port to a new platform your criteria would be different. Also, note > that the above page was last updated in April 2014. Look at the info > for that page: > > https://wiki.python.org/moin/Python2orPython3?action=info > > and you'll see there was probably nothing of substance added to that > page in over a year. > Something to keep in mind is that i'm using an Android tablet for building and troubleshooting errors...which means webpages have different layouts. The change date for the wiki page I referenced is waaaay down at the bottom, in extra small, faint type. I wasn't aware the info was for those using Python. > Right at the very top of that page, I read: > > Short version: Python 2.x is legacy, Python 3.x is the present and > future of the language > > I would think that would be enough to convince you to use Python 3.x > as your starting point. It was, initially, until I read (most of) the rest of the article I say this as someone who, in his day-to-day > work uses Python 2.7 exclusively, doesn't expect his employer to ever > convert to Python 3, and has never done much more with Python 3 than > build it. With all that, if I was going to attempt a port of Python to > a new platform, I would still choose to port Python 3. > > Skip Noted. Will proceed with the 3.x releass. From v+python at g.nevcal.com Tue Jan 27 21:45:28 2015 From: v+python at g.nevcal.com (Glenn Linderman) Date: Tue, 27 Jan 2015 12:45:28 -0800 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: Message-ID: <54C7F8E8.8080708@g.nevcal.com> On 1/27/2015 8:04 AM, Cyd Haselton wrote: > Noted. Will proceed with the 3.x releass. I had been excited you were working on Android Python until I realized you were working on 2.x. I started with Python 3, and have only dabbled in 2.x for a couple projects that had unported dependency needs. One of them, reportlab, was ported in the last year, and the other is my web server CGI ports which is still constrained by a couple libraries, and although I think they may have recently been ported, I haven't had time to upgrade it. Probably will by April, when I have to ditch my Google OpenID login system, because they have abandoned it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arigo at tunes.org Tue Jan 27 23:12:09 2015 From: arigo at tunes.org (Armin Rigo) Date: Tue, 27 Jan 2015 23:12:09 +0100 Subject: [Python-Dev] PEP 468 (Ordered kwargs) In-Reply-To: References: Message-ID: Hi all, On 24 January 2015 at 11:50, Maciej Fijalkowski wrote: > I would like to point out that we implemented rhettingers idea in PyPy > that makes all the dicts ordered by default and we don't have any > adverse performance effects (in fact, there is quite significant > memory saving coming from it). The measurments on CPython could be > different, but in principle OrderedDict can be implemented as > efficiently as normal dict. I would like to add that http://bugs.python.org/issue16991 is the same as today's dicts with an additional doubly-linked list for the order. I'm unsure why you would do that after the 2012 thread started by Raymond Hettinger, but anyway, don't conclude from only this that in the CPython case ordered dictionaries would be slower and bigger. My guess is that, with a simple port of what is now in PyPy, they would not be (but of course no-one can be sure at this point). Let's say, if you could imagine that CPython's dictionaries, tomorrow, are always magically fully ordered, then would it still be a bad idea? If such a discussion would resurface (soon or "one day"), and if other related issues are resolved (like what to do in Jython and IronPython), and if the conclusion would tentatively turn out positive... then, provided there would at that point still be no "Raymond-style" implementation of dicts, I would volunteer to port PyPy's one to CPython[1]. As you may have guessed I don't consider this particularly likely to occur, but it is a standing offer nevertheless :-) A bient?t, Armin. [1] Someone could also do such a port for the goal of getting an alternate `odictobject.c`. He would be welcome to #pypy to get some help from the PyPy guys, including me --- but my offer above doesn't apply in this case. I want to remove a thorn in the foot of python-dev discussing about the language; I'm not really interested in contributing to the `collections.OrderedDict` type. From chaselton at gmail.com Wed Jan 28 00:28:19 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Tue, 27 Jan 2015 17:28:19 -0600 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: <54C7F8E8.8080708@g.nevcal.com> References: <54C7F8E8.8080708@g.nevcal.com> Message-ID: On Tue, Jan 27, 2015 at 2:45 PM, Glenn Linderman wrote: > On 1/27/2015 8:04 AM, Cyd Haselton wrote: > > Noted. Will proceed with the 3.x releass. > > I had been excited you were working on Android Python until I realized you > were working on 2.x. I started with Python 3, and have only dabbled in 2.x > for a couple projects that had unported dependency needs. One of them, > reportlab, was ported in the last year, and the other is my web server CGI > ports which is still constrained by a couple libraries, and although I think > they may have recently been ported, I haven't had time to upgrade it. > Probably will by April, when I have to ditch my Google OpenID login system, > because they have abandoned it. > Well, you can start being cautiously excited again now that I'm working on the 3.4.2 release. I use cautiously for several reasons...chief among them being the severely limited Android libc. From greg at krypto.org Wed Jan 28 08:14:12 2015 From: greg at krypto.org (Gregory P. Smith) Date: Wed, 28 Jan 2015 07:14:12 +0000 Subject: [Python-Dev] PEP 468 (Ordered kwargs) References: Message-ID: On Tue Jan 27 2015 at 2:13:08 PM Armin Rigo wrote: > Hi all, > > On 24 January 2015 at 11:50, Maciej Fijalkowski wrote: > > I would like to point out that we implemented rhettingers idea in PyPy > > that makes all the dicts ordered by default and we don't have any > > adverse performance effects (in fact, there is quite significant > > memory saving coming from it). The measurments on CPython could be > > different, but in principle OrderedDict can be implemented as > > efficiently as normal dict. > > I would like to add that http://bugs.python.org/issue16991 is the same > as today's dicts with an additional doubly-linked list for the order. > I'm unsure why you would do that after the 2012 thread started by > Raymond Hettinger, but anyway, don't conclude from only this that in > the CPython case ordered dictionaries would be slower and bigger. My > guess is that, with a simple port of what is now in PyPy, they would > not be (but of course no-one can be sure at this point). Let's say, > if you could imagine that CPython's dictionaries, tomorrow, are always > magically fully ordered, then would it still be a bad idea? > It is a potentially bad idea if order is the default behavior of iteration, items(), keys() and values(). Ideally order should only be exposed when explicitly asked for to help prevent bugs and mitigate potential information leaks. But I'm not sure how big of a deal this actually is. The insertion order nicely doesn't give away anything related to the hash seed used for hash randomization which is a nice bonus over today's implementation (and 2.7 & 3.3's very poor hash randomization implementation). Experience cleaning up our huge code base at work to turn on hash randomization by default a couple years ago has shown that people depend on iteration order in code often without intending to. This often leads to latent bugs. Keep iteration order unstable by default and you prevent people from doing that. Make people request an ordered or stable iteration when their code explicitly needs it. If such a discussion would resurface (soon or "one day"), and if other > related issues are resolved (like what to do in Jython and > IronPython), and if the conclusion would tentatively turn out > positive... then, provided there would at that point still be no > "Raymond-style" implementation of dicts, I would volunteer to port > PyPy's one to CPython[1]. As you may have guessed I don't consider > this particularly likely to occur, but it is a standing offer > nevertheless :-) > CPython should benefit from it regardless for the memory savings alone. -gps > > A bient?t, > > Armin. > > > [1] Someone could also do such a port for the goal of getting an > alternate `odictobject.c`. He would be welcome to #pypy to get some > help from the PyPy guys, including me --- but my offer above doesn't > apply in this case. I want to remove a thorn in the foot of > python-dev discussing about the language; I'm not really interested in > contributing to the `collections.OrderedDict` type. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > greg%40krypto.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at simplistix.co.uk Wed Jan 28 10:14:21 2015 From: chris at simplistix.co.uk (Chris Withers) Date: Wed, 28 Jan 2015 09:14:21 +0000 Subject: [Python-Dev] PEP 468 (Ordered kwargs) In-Reply-To: References: Message-ID: <54C8A86D.1060401@simplistix.co.uk> On 28/01/2015 07:14, Gregory P. Smith wrote: > > It is a potentially bad idea if order is the default behavior of > iteration, items(), keys() and values(). Ideally order should only be > exposed when explicitly asked for to help prevent bugs and mitigate > potential information leaks. I have to be honest, I think that's the opposite of most new users assumption... > Experience cleaning up our huge code base at work to turn on hash > randomization by default a couple years ago has shown that people depend > on iteration order in code often without intending to. This often leads > to latent bugs. Keep iteration order unstable by default and you prevent > people from doing that. Hmm, well, or you could say that always having ordering would mean the behaviour would match new users experimental understanding and so eliminate all bugs that occur when people accidentally rely on ordering. Personally, I'd prefer to see us be explicit about data structures used when "security matters", an explicit RandomOrderedDict would make that clear. cheers, Chris From agriff at tin.it Wed Jan 28 10:22:04 2015 From: agriff at tin.it (Andrea Griffini) Date: Wed, 28 Jan 2015 10:22:04 +0100 Subject: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts? Message-ID: Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts? Andrea -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.ewing at canterbury.ac.nz Wed Jan 28 12:21:08 2015 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 29 Jan 2015 00:21:08 +1300 Subject: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts? In-Reply-To: References: Message-ID: <54C8C624.8050802@canterbury.ac.nz> Andrea Griffini wrote: > Sorry if the question is naive, but why is co_names needed? Wouldn't be > simpler to just use co_consts? One reason might be that keeping them separate means you can have up to 256 names and 256 consts using 1-byte opcode arguments. Otherwise, you'd be limited to a total of 256 of both. -- Greg From ncoghlan at gmail.com Wed Jan 28 13:40:13 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Wed, 28 Jan 2015 22:40:13 +1000 Subject: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts? In-Reply-To: <54C8C624.8050802@canterbury.ac.nz> References: <54C8C624.8050802@canterbury.ac.nz> Message-ID: On 28 January 2015 at 21:21, Greg Ewing wrote: > Andrea Griffini wrote: >> >> Sorry if the question is naive, but why is co_names needed? Wouldn't be >> simpler to just use co_consts? > > One reason might be that keeping them separate means > you can have up to 256 names and 256 consts using > 1-byte opcode arguments. Otherwise, you'd be limited > to a total of 256 of both. They're logically distinct things accessed by different opcodes for very different purposes. While you theoretically *could* use one array to hold both, it would make the eval code harder to read, and various introspection tasks (like "tell me all the names referenced from this code object") significantly more difficult. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From aarmour at cipmail.org Wed Jan 28 15:23:37 2015 From: aarmour at cipmail.org (Alan Armour) Date: Wed, 28 Jan 2015 09:23:37 -0500 Subject: [Python-Dev] development Message-ID: can you guys develop an audio kit that works around jackd or on windows directx? and tutorials to write synthesizers. and drum machines like a tr-606 with triggers ( I want to trigger a drum synth like the March UDS(Soviet).... Coolest drum synth EVER. Also, I think you should have a way to write assembler functions to really optimize speed and have a table and stuff for assembler learning for all cpus and stuff. even asm graphics and audio would be super useful in some instances. Thanks for your time -Ty -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Wed Jan 28 15:43:27 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Wed, 28 Jan 2015 08:43:27 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault Message-ID: 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 From brian at python.org Wed Jan 28 15:52:09 2015 From: brian at python.org (Brian Curtin) Date: Wed, 28 Jan 2015 08:52:09 -0600 Subject: [Python-Dev] development In-Reply-To: References: Message-ID: On Wednesday, January 28, 2015, Alan Armour wrote: > can you guys develop an audio kit that works around jackd or on windows > directx? and tutorials to write synthesizers. and drum machines like a > tr-606 with triggers ( I want to trigger a drum synth like the March > UDS(Soviet).... Coolest drum synth EVER. > > > Also, I think you should have a way to write assembler functions to really > optimize speed and have a table and stuff for assembler learning for all > cpus and stuff. even asm graphics and audio would be super useful in some > instances. > That's not how this works. If you would like to write all of that code and allow it to mature in the wild while building a following around it and ensuring it is the best of its kind and a general enough solution to be included in the Python standard library, inclusion of that could be discussed in the future. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aarmour at cipmail.org Wed Jan 28 15:39:25 2015 From: aarmour at cipmail.org (Alan Armour) Date: Wed, 28 Jan 2015 09:39:25 -0500 Subject: [Python-Dev] also Message-ID: if you can do this.... a chemical physics and element physics like everything from melting points to how much heat you need to add two chemicals together and physics like aerodynamics, space dynamics, and hydrodynamics etcetera for propellers and motors and stuff. just having this in a main language seems to make a shit ton of sense. Just like all the physics you can think of from electrical equipment to building microchips to oscillators and resistors and stuff like that. thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From brett at python.org Wed Jan 28 16:29:12 2015 From: brett at python.org (Brett Cannon) Date: Wed, 28 Jan 2015 15:29:12 +0000 Subject: [Python-Dev] also References: Message-ID: You have the wrong mailing list for this sort of request. This is list is about the development *of* Python, not *with* it. And since Python the language is not in the business of providing libraries for such specific needs this kind of request isn't appropriate here. You can try asking somewhere like python-list to see if a library already exists for your needs, though. On Wed Jan 28 2015 at 10:13:03 AM Alan Armour wrote: > if you can do this.... > > a chemical physics and element physics like everything from melting points > to how much heat you need to add two chemicals together > > and physics like aerodynamics, space dynamics, and hydrodynamics etcetera > for propellers and motors and stuff. > > just having this in a main language seems to make a shit ton of sense. > > > Just like all the physics you can think of from electrical equipment to > building microchips to oscillators and resistors and stuff like that. > > thanks > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > brett%40python.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guido at python.org Wed Jan 28 16:43:42 2015 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Jan 2015 07:43:42 -0800 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: 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 wrote: > All, > I recently ditched my attempts to port Python 2.7.8 to Android in > favor of Python 3.4.2. Unfortunately, after using the same configure > options in the same environment, and modifying the setup.py as needed, > the newly built binary throws a segfault when the generate-posix-vars > portion of the build is reached...and when it is run as well (i.e. > ./python --help, ./python -E -S -m sysconfig, or similar) > > I took a strace of ./python, however I'm a bit lost when reviewing it. > Any ideas as to what may be going on...i.e. why Python 2.7 works but > 3.x throws a segfault? > > Thanks in advance, > Cyd > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From python at mrabarnett.plus.com Wed Jan 28 16:52:27 2015 From: python at mrabarnett.plus.com (MRAB) Date: Wed, 28 Jan 2015 15:52:27 +0000 Subject: [Python-Dev] also In-Reply-To: References: Message-ID: <54C905BB.3050605@mrabarnett.plus.com> On 2015-01-28 14:39, Alan Armour wrote: > if you can do this.... > > a chemical physics and element physics like everything from melting > points to how much heat you need to add two chemicals together > > and physics like aerodynamics, space dynamics, and hydrodynamics > etcetera for propellers and motors and stuff. > > just having this in a main language seems to make a shit ton of sense. > > > Just like all the physics you can think of from electrical equipment to > building microchips to oscillators and resistors and stuff like that. > > thanks > You should be looking at Wolfram Alpha instead... From guido at python.org Wed Jan 28 17:43:00 2015 From: guido at python.org (Guido van Rossum) Date: Wed, 28 Jan 2015 08:43:00 -0800 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: 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. That stack trace would be really helpful. On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 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 > 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 > wrote: > >> > >> All, > >> I recently ditched my attempts to port Python 2.7.8 to Android in > >> favor of Python 3.4.2. Unfortunately, after using the same configure > >> options in the same environment, and modifying the setup.py as needed, > >> the newly built binary throws a segfault when the generate-posix-vars > >> portion of the build is reached...and when it is run as well (i.e. > >> ./python --help, ./python -E -S -m sysconfig, or similar) > >> > >> I took a strace of ./python, however I'm a bit lost when reviewing it. > >> Any ideas as to what may be going on...i.e. why Python 2.7 works but > >> 3.x throws a segfault? > >> > >> Thanks in advance, > >> Cyd > >> _______________________________________________ > >> Python-Dev mailing list > >> Python-Dev at python.org > >> https://mail.python.org/mailman/listinfo/python-dev > >> Unsubscribe: > >> https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > > > > > > -- > > --Guido van Rossum (python.org/~guido) > -- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Wed Jan 28 17:34:04 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Wed, 28 Jan 2015 10:34:04 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: 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 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 wrote: >> >> All, >> I recently ditched my attempts to port Python 2.7.8 to Android in >> favor of Python 3.4.2. Unfortunately, after using the same configure >> options in the same environment, and modifying the setup.py as needed, >> the newly built binary throws a segfault when the generate-posix-vars >> portion of the build is reached...and when it is run as well (i.e. >> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >> 3.x throws a segfault? >> >> Thanks in advance, >> Cyd >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (python.org/~guido) -------------- next part -------------- A non-text attachment was scrubbed... Name: sout Type: application/octet-stream Size: 9149 bytes Desc: not available URL: From rymg19 at gmail.com Wed Jan 28 18:23:53 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Wed, 28 Jan 2015 11:23:53 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: > What I see in the strace: > > ... load libpython3.4m.so.1.0 > ... load libm > ... open /dev/__properties__ and do something to it (what?) > ... get current time > ... allocate memory > ... getuid > ... segfault > > That's not a lot to go on, but it doesn't look as if it has started to > load modules yet. > > Does /dev/__properties__ ring a bell? Not to me. > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c is the code that works with that file. This explains it a bit (slides 24-29). Looks like something to do with interprocess communication. Likely has nothing to do with Python itself. Maybe this would be useful? > That stack trace would be really helpful. > > On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 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 >> 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 >> wrote: >> >> >> >> All, >> >> I recently ditched my attempts to port Python 2.7.8 to Android in >> >> favor of Python 3.4.2. Unfortunately, after using the same configure >> >> options in the same environment, and modifying the setup.py as needed, >> >> the newly built binary throws a segfault when the generate-posix-vars >> >> portion of the build is reached...and when it is run as well (i.e. >> >> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> >> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >> >> 3.x throws a segfault? >> >> >> >> Thanks in advance, >> >> Cyd >> >> _______________________________________________ >> >> Python-Dev mailing list >> >> Python-Dev at python.org >> >> https://mail.python.org/mailman/listinfo/python-dev >> >> Unsubscribe: >> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > >> > >> > >> > >> > -- >> > --Guido van Rossum (python.org/~guido) >> > > > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From agriff at tin.it Wed Jan 28 19:53:20 2015 From: agriff at tin.it (Andrea Griffini) Date: Wed, 28 Jan 2015 19:53:20 +0100 Subject: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts? In-Reply-To: References: <54C8C624.8050802@canterbury.ac.nz> Message-ID: The names stored in op_names are totally unrelated as they can be attribute names, module names, global names; you basically don't know much about them unless you also inspect the actual bytecode using them (and the same name can be used in completely different ways in different parts of the same code object). In my opinion introspection code telling me that the name `foo` is used but not knowing if it's about a global, a module name or an attribute name is not going to be that useful, on the other hand if you do inspect the bytecode then using co_consts doesn't make things more complicate. Anyway I was just curious to know if there was any technical reason (that I couldn't see) or if it was more a style/historic reason. Thank you for the clarification On Wed, Jan 28, 2015 at 1:40 PM, Nick Coghlan wrote: > On 28 January 2015 at 21:21, Greg Ewing > wrote: > > Andrea Griffini wrote: > >> > >> Sorry if the question is naive, but why is co_names needed? Wouldn't be > >> simpler to just use co_consts? > > > > One reason might be that keeping them separate means > > you can have up to 256 names and 256 consts using > > 1-byte opcode arguments. Otherwise, you'd be limited > > to a total of 256 of both. > > They're logically distinct things accessed by different opcodes for > very different purposes. While you theoretically *could* use one array > to hold both, it would make the eval code harder to read, and various > introspection tasks (like "tell me all the names referenced from this > code object") significantly more difficult. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/agriff%40tin.it > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Wed Jan 28 23:42:33 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Wed, 28 Jan 2015 16:42:33 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: That is interesting.../dev/__properties__ is in memory...not the filesystem, apparently proccesses read global properties from it. It's read-only...not sure why the build or the python binary would access it...or if that's the cause of the segfault. I have root access on the tablet so I was able to check for the traces.txt file. There are a number of them, but none contain information about the segfault. On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez wrote: > On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: >> >> What I see in the strace: >> >> ... load libpython3.4m.so.1.0 >> ... load libm >> ... open /dev/__properties__ and do something to it (what?) >> ... get current time >> ... allocate memory >> ... getuid >> ... segfault >> >> That's not a lot to go on, but it doesn't look as if it has started to >> load modules yet. >> >> Does /dev/__properties__ ring a bell? Not to me. >> > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > is the code that works with that file. > > This explains it a bit (slides 24-29). Looks like something to do with > interprocess communication. Likely has nothing to do with Python itself. > > Maybe this would be useful? > >> >> That stack trace would be really helpful. >> >> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 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 >>> 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 >>> > wrote: >>> >> >>> >> All, >>> >> I recently ditched my attempts to port Python 2.7.8 to Android in >>> >> favor of Python 3.4.2. Unfortunately, after using the same configure >>> >> options in the same environment, and modifying the setup.py as needed, >>> >> the newly built binary throws a segfault when the generate-posix-vars >>> >> portion of the build is reached...and when it is run as well (i.e. >>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>> >> 3.x throws a segfault? >>> >> >>> >> Thanks in advance, >>> >> Cyd >>> >> _______________________________________________ >>> >> Python-Dev mailing list >>> >> Python-Dev at python.org >>> >> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> > >>> > >>> > >>> > >>> > -- >>> > --Guido van Rossum (python.org/~guido) >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ From steve at pearwood.info Thu Jan 29 00:38:51 2015 From: steve at pearwood.info (Steven D'Aprano) Date: Thu, 29 Jan 2015 10:38:51 +1100 Subject: [Python-Dev] also In-Reply-To: References: Message-ID: <20150128233851.GA2498@ando.pearwood.info> On Wed, Jan 28, 2015 at 09:39:25AM -0500, Alan Armour wrote: > if you can do this.... > > a chemical physics and element physics like everything from melting points > to how much heat you need to add two chemicals together > > and physics like aerodynamics, space dynamics, and hydrodynamics etcetera > for propellers and motors and stuff. > > just having this in a main language seems to make a shit ton of sense. You should check out Frink: http://futureboy.us/frinkdocs/ -- Steve From chris.barker at noaa.gov Thu Jan 29 06:08:09 2015 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Wed, 28 Jan 2015 21:08:09 -0800 Subject: [Python-Dev] Pydoc Replacement for Python's help()? In-Reply-To: References: <54C7F8E8.8080708@g.nevcal.com> Message-ID: <-5603876186594649743@unknownmsgid> Just want to make sure you're aware of the new mobile-sig: https://mail.python.org/mailman/listinfo/mobile-sig No need to do this on your own. -Chris > On Jan 27, 2015, at 4:21 PM, Cyd Haselton wrote: > >> On Tue, Jan 27, 2015 at 2:45 PM, Glenn Linderman wrote: >> On 1/27/2015 8:04 AM, Cyd Haselton wrote: >> >> Noted. Will proceed with the 3.x releass. >> >> I had been excited you were working on Android Python until I realized you >> were working on 2.x. I started with Python 3, and have only dabbled in 2.x >> for a couple projects that had unported dependency needs. One of them, >> reportlab, was ported in the last year, and the other is my web server CGI >> ports which is still constrained by a couple libraries, and although I think >> they may have recently been ported, I haven't had time to upgrade it. >> Probably will by April, when I have to ditch my Google OpenID login system, >> because they have abandoned it. > Well, you can start being cautiously excited again now that I'm > working on the 3.4.2 release. > > I use cautiously for several reasons...chief among them being the > severely limited Android libc. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov From ncoghlan at gmail.com Thu Jan 29 15:08:16 2015 From: ncoghlan at gmail.com (Nick Coghlan) Date: Fri, 30 Jan 2015 00:08:16 +1000 Subject: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts? In-Reply-To: References: <54C8C624.8050802@canterbury.ac.nz> Message-ID: On 29 January 2015 at 04:53, Andrea Griffini wrote: > The names stored in op_names are totally unrelated as they can be attribute > names, module names, global names; you basically don't know much about them > unless you also inspect the actual bytecode using them (and the same name > can be used in completely different ways in different parts of the same code > object). In my opinion introspection code telling me that the name `foo` is > used but not knowing if it's about a global, a module name or an attribute > name is not going to be that useful, on the other hand if you do inspect the > bytecode then using co_consts doesn't make things more complicate. It makes more sense once you know there are a couple of related passes over the AST in the compiler, one to build the symbol table (i.e. just looking at what names exist, where they're defined, and what references them), and a second pass to do the actual code generation (already armed with the symbol details from the symbol table pass). So co_names relates to things that come up in the symbol table pass, while co_consts is only relevant to actual code generation and execution. co_names also doesn't get used in isolation - it's combined with co_varnames and various other attributes in a way that's actually structured more for the convenience of the interpreter eval loop than it is for human readers. As a general rule, by the time we get to the code object level, we're well down into the weeds of needing to think about how the underlying Python interpreter *works*, rather than just what it allows a Python programmer to do. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia From brunocauet at gmail.com Thu Jan 29 18:49:16 2015 From: brunocauet at gmail.com (Bruno Cauet) Date: Thu, 29 Jan 2015 18:49:16 +0100 Subject: [Python-Dev] Results of the python 2.x and 3.x use survey, 2014 edition Message-ID: Hi! Finally, here are the results: http://blog.frite-camembert.net/python-survey-2014.html Here is the auto-generated Google Forms recap: https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewanalytics (more elegant than my matplotlib graphs - I'd have no future as a designer). Overall people started writing more python 3: +15 points in "I ever wrote python 3 code", +10 points in "I write more python 3 than 2". Transition is still ongoing and I hope a tipping point will be soon be attained. Users definitely seem to want to switch to python 3, but dependencies keep them with 2.7 (I weep for the few ones still on 2.5). I also posted the results on HN (https://news.ycombinator.com/item?id=8967645) and reddit (http://www.reddit.com/r/Python/comments/2u3oh0/results_of_the_python_2x_and_3x_use_survey_2014/). Have a nice day, and a year full of python 3! Bruno Cauet From chaselton at gmail.com Fri Jan 30 00:32:45 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Thu, 29 Jan 2015 17:32:45 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: Found a patch for at bugs.python.org addressing a segfault issue for android but even afternapplying it i'm still getting a segfault. I ran a strace with the verbose option and am attaching it to this update. If not helpful, I'll see if I can hook up the debugging bridge to the tablet but as mentioned earlier there was no helpful info in the anr/traces files On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez wrote: > On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: >> >> What I see in the strace: >> >> ... load libpython3.4m.so.1.0 >> ... load libm >> ... open /dev/__properties__ and do something to it (what?) >> ... get current time >> ... allocate memory >> ... getuid >> ... segfault >> >> That's not a lot to go on, but it doesn't look as if it has started to >> load modules yet. >> >> Does /dev/__properties__ ring a bell? Not to me. >> > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > is the code that works with that file. > > This explains it a bit (slides 24-29). Looks like something to do with > interprocess communication. Likely has nothing to do with Python itself. > > Maybe this would be useful? > >> >> That stack trace would be really helpful. >> >> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 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 >>> 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 >>> > wrote: >>> >> >>> >> All, >>> >> I recently ditched my attempts to port Python 2.7.8 to Android in >>> >> favor of Python 3.4.2. Unfortunately, after using the same configure >>> >> options in the same environment, and modifying the setup.py as needed, >>> >> the newly built binary throws a segfault when the generate-posix-vars >>> >> portion of the build is reached...and when it is run as well (i.e. >>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>> >> 3.x throws a segfault? >>> >> >>> >> Thanks in advance, >>> >> Cyd >>> >> _______________________________________________ >>> >> Python-Dev mailing list >>> >> Python-Dev at python.org >>> >> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> > >>> > >>> > >>> > >>> > -- >>> > --Guido van Rossum (python.org/~guido) >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- A non-text attachment was scrubbed... Name: sout-1024 Type: application/octet-stream Size: 11701 bytes Desc: not available URL: From solipsis at pitrou.net Fri Jan 30 02:21:38 2015 From: solipsis at pitrou.net (Antoine Pitrou) Date: Fri, 30 Jan 2015 02:21:38 +0100 Subject: [Python-Dev] Pronouncing on PEP 475 - last call Message-ID: <20150130022138.6f6ba887@fsol> Hello, As BDFL-delegate, I'd like to pronounce soon on PEP 475 - "Retry system calls failing with EINTR". I've just pushed some small rephrasings, which should appear soon (at https://www.python.org/dev/peps/pep-0475/). There is a working implementation by Charles-Fran?ois at http://bugs.python.org/issue23285. If you have anything to say, please chime in quick :-) Regards Antoine. From chaselton at gmail.com Fri Jan 30 02:32:56 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Thu, 29 Jan 2015 19:32:56 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: 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 wrote: > On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum wrote: >> >> What I see in the strace: >> >> ... load libpython3.4m.so.1.0 >> ... load libm >> ... open /dev/__properties__ and do something to it (what?) >> ... get current time >> ... allocate memory >> ... getuid >> ... segfault >> >> That's not a lot to go on, but it doesn't look as if it has started to >> load modules yet. >> >> Does /dev/__properties__ ring a bell? Not to me. >> > > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > is the code that works with that file. > > This explains it a bit (slides 24-29). Looks like something to do with > interprocess communication. Likely has nothing to do with Python itself. > > Maybe this would be useful? > >> >> That stack trace would be really helpful. >> >> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton 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 >>> 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 >>> > wrote: >>> >> >>> >> All, >>> >> I recently ditched my attempts to port Python 2.7.8 to Android in >>> >> favor of Python 3.4.2. Unfortunately, after using the same configure >>> >> options in the same environment, and modifying the setup.py as needed, >>> >> the newly built binary throws a segfault when the generate-posix-vars >>> >> portion of the build is reached...and when it is run as well (i.e. >>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>> >> I took a strace of ./python, however I'm a bit lost when reviewing it. >>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>> >> 3.x throws a segfault? >>> >> >>> >> Thanks in advance, >>> >> Cyd >>> >> _______________________________________________ >>> >> Python-Dev mailing list >>> >> Python-Dev at python.org >>> >> https://mail.python.org/mailman/listinfo/python-dev >>> >> Unsubscribe: >>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> > >>> > >>> > >>> > >>> > -- >>> > --Guido van Rossum (python.org/~guido) >> >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ From rymg19 at gmail.com Fri Jan 30 03:26:26 2015 From: rymg19 at gmail.com (Ryan) Date: Thu, 29 Jan 2015 20:26:26 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> 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 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 >wrote: >> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >wrote: >>> >>> What I see in the strace: >>> >>> ... load libpython3.4m.so.1.0 >>> ... load libm >>> ... open /dev/__properties__ and do something to it (what?) >>> ... get current time >>> ... allocate memory >>> ... getuid >>> ... segfault >>> >>> That's not a lot to go on, but it doesn't look as if it has started >to >>> load modules yet. >>> >>> Does /dev/__properties__ ring a bell? Not to me. >>> >> >> >https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> is the code that works with that file. >> >> This explains it a bit (slides 24-29). Looks like something to do >with >> interprocess communication. Likely has nothing to do with Python >itself. >> >> Maybe this would be useful? >> >>> >>> That stack trace would be really helpful. >>> >>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >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 > >>>> 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 > >>>> > wrote: >>>> >> >>>> >> All, >>>> >> I recently ditched my attempts to port Python 2.7.8 to Android >in >>>> >> favor of Python 3.4.2. Unfortunately, after using the same >configure >>>> >> options in the same environment, and modifying the setup.py as >needed, >>>> >> the newly built binary throws a segfault when the >generate-posix-vars >>>> >> portion of the build is reached...and when it is run as well >(i.e. >>>> >> ./python --help, ./python -E -S -m sysconfig, or similar) >>>> >> >>>> >> I took a strace of ./python, however I'm a bit lost when >reviewing it. >>>> >> Any ideas as to what may be going on...i.e. why Python 2.7 works >but >>>> >> 3.x throws a segfault? >>>> >> >>>> >> Thanks in advance, >>>> >> Cyd >>>> >> _______________________________________________ >>>> >> Python-Dev mailing list >>>> >> Python-Dev at python.org >>>> >> https://mail.python.org/mailman/listinfo/python-dev >>>> >> Unsubscribe: >>>> >> >https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > --Guido van Rossum (python.org/~guido) >>> >>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev at python.org >>> https://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> >https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>> >> >> >> >> -- >> Ryan >> If anybody ever asks me why I prefer C++ to C, my answer will be >simple: >> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that >was >> nul-terminated." >> Personal reality distortion fields are immune to contradictory >evidence. - >> srean >> Check out my website: http://kirbyfan64.github.io/ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mistersheik at gmail.com Fri Jan 30 13:07:51 2015 From: mistersheik at gmail.com (Neil Girdhar) Date: Fri, 30 Jan 2015 07:07:51 -0500 Subject: [Python-Dev] Code review for PEP 448 Message-ID: Hello all, PEP 448 (https://www.python.org/dev/peps/pep-0448/) is mostly implemented now based on some early implementations by twouters (in 2008) and fhahn (2013) and recently by Joshua and I. The issue tracker http://bugs.python.org/issue2292 has: * a working patch, and * discussion and updates to the PEP (the most conservative interpretations were taken). I was wondering if anyone would mind reviewing the patch or even just trying it out to let us know if there are any corner cases that we missed. (I need to get back to my actual work, so it would be good to have this reviewed before I forget everything if possible.) Thank you, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Fri Jan 30 16:05:13 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 09:05:13 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 wrote: >>> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >>> wrote: >>>> >>>> >>>> What I see in the strace: >>>> >>>> ... load libpython3.4m.so.1.0 >>>> ... load libm >>>> ... open /dev/__properties__ and do something to it >>>> (what?) >>>> ... get current time >>>> ... allocate memory >>>> ... getuid >>>> ... segfault >>>> >>>> That's not a lot to go on, but it doesn't look as if it has started to >>>> load modules yet. >>>> >>>> Does /dev/__properties__ ring a bell? Not to me. >>> >>> >>> >>> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>> is the code that works with that file. >>> >>> This explains it a bit (slides 24-29). Looks like something to do with >>> interprocess communication. Likely has nothing to do with Python itself. >>> >>> Maybe this would be useful? >>> >>>> >>>> That stack trace would be really helpful. >>>> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>>> 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 >>>>> 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 >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> All, >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android in >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >>>>>>> configure >>>>>>> options in the same environment, and modifying the setup.py as >>>>>>> needed, >>>>>>> the newly built binary throws a segfault when the >>>>>>> generate-posix-vars >>>>>>> portion of the build is reached...and when it is run as well (i.e. >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >>>>>>> >>>>>>> I took a strace of ./python, however I'm a bit lost when reviewing >>>>>>> it. >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>>>>>> 3.x throws a segfault? >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Cyd >>>>>>> ________________________________ >>>>>>> >>>>>>> Python-Dev mailing list >>>>>>> >>>>>>> Python-Dev at python.org >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>>> Unsubscribe: >>>>>>> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --Guido van Rossum (python.org/~guido) >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> --Guido van Rossum (python.org/~guido) >>>> >>>> ________________________________ >>>> >>>> Python-Dev mailing list >>>> Python-Dev at python.org >>>> https://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>> >>> >>> >>> >>> >>> -- >>> Ryan >>> If anybody ever asks me why I prefer C++ to C, my answer will be simple: >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >>> nul-terminated." >>> Personal reality distortion fields are immune to contradictory evidence. >>> - >>> srean >>> Check out my website: http://kirbyfan64.github.io/ > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > Check out my website: http://kirbyfan64.github.io/ From chaselton at gmail.com Fri Jan 30 16:29:05 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 09:29:05 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 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 wrote: >>>> >>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >>>> wrote: >>>>> >>>>> >>>>> What I see in the strace: >>>>> >>>>> ... load libpython3.4m.so.1.0 >>>>> ... load libm >>>>> ... open /dev/__properties__ and do something to it >>>>> (what?) >>>>> ... get current time >>>>> ... allocate memory >>>>> ... getuid >>>>> ... segfault >>>>> >>>>> That's not a lot to go on, but it doesn't look as if it has started to >>>>> load modules yet. >>>>> >>>>> Does /dev/__properties__ ring a bell? Not to me. >>>> >>>> >>>> >>>> >>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>>> is the code that works with that file. >>>> >>>> This explains it a bit (slides 24-29). Looks like something to do with >>>> interprocess communication. Likely has nothing to do with Python itself. >>>> >>>> Maybe this would be useful? >>>> >>>>> >>>>> That stack trace would be really helpful. >>>>> >>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>>>> 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 >>>>>> 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 >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> All, >>>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android in >>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >>>>>>>> configure >>>>>>>> options in the same environment, and modifying the setup.py as >>>>>>>> needed, >>>>>>>> the newly built binary throws a segfault when the >>>>>>>> generate-posix-vars >>>>>>>> portion of the build is reached...and when it is run as well (i.e. >>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >>>>>>>> >>>>>>>> I took a strace of ./python, however I'm a bit lost when reviewing >>>>>>>> it. >>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>>>>>>> 3.x throws a segfault? >>>>>>>> >>>>>>>> Thanks in advance, >>>>>>>> Cyd >>>>>>>> ________________________________ >>>>>>>> >>>>>>>> Python-Dev mailing list >>>>>>>> >>>>>>>> Python-Dev at python.org >>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>>>> Unsubscribe: >>>>>>>> >>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --Guido van Rossum (python.org/~guido) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --Guido van Rossum (python.org/~guido) >>>>> >>>>> ________________________________ >>>>> >>>>> Python-Dev mailing list >>>>> Python-Dev at python.org >>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>> Unsubscribe: >>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Ryan >>>> If anybody ever asks me why I prefer C++ to C, my answer will be simple: >>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >>>> nul-terminated." >>>> Personal reality distortion fields are immune to contradictory evidence. >>>> - >>>> srean >>>> Check out my website: http://kirbyfan64.github.io/ >> >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> Check out my website: http://kirbyfan64.github.io/ From status at bugs.python.org Fri Jan 30 18:08:12 2015 From: status at bugs.python.org (Python tracker) Date: Fri, 30 Jan 2015 18:08:12 +0100 (CET) Subject: [Python-Dev] Summary of Python tracker Issues Message-ID: <20150130170812.EB84C562DB@psf.upfronthosting.co.za> ACTIVITY SUMMARY (2015-01-23 - 2015-01-30) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 4764 ( +4) closed 30351 (+44) total 35115 (+48) Open issues with patches: 2224 Issues opened (38) ================== #21076: Turn signal.SIG* constants into enums http://bugs.python.org/issue21076 reopened by serhiy.storchaka #23306: Within zipfile, use of zlib.crc32 raises OverflowError at argu http://bugs.python.org/issue23306 opened by Danny.Yoo #23308: a bug in Instructions section 4.1 http://bugs.python.org/issue23308 opened by Dmot #23309: Hang on interpreter shutdown if daemon thread prints to stdout http://bugs.python.org/issue23309 opened by marienz #23310: MagicMock constructor configuration fails for magic methods http://bugs.python.org/issue23310 opened by berdario #23311: Update PC/example_nt and extending/windows.rst http://bugs.python.org/issue23311 opened by steve.dower #23312: google thinks the docs are mobile unfriendly http://bugs.python.org/issue23312 opened by benjamin.peterson #23314: Disabling CRT asserts in debug build http://bugs.python.org/issue23314 opened by steve.dower #23315: tempfile.mkdtemp fails with non-ascii paths on Python 2 http://bugs.python.org/issue23315 opened by akira #23316: Incorrect evaluation order of function arguments with *args http://bugs.python.org/issue23316 opened by Joshua.Landau #23317: Incorrect description of descriptor invocation in Python Langu http://bugs.python.org/issue23317 opened by Justin.Eldridge #23319: Missing SWAP_INT??in I_set_sw http://bugs.python.org/issue23319 opened by mgautierfr #23320: devguide should mention rules about "paragraph reflow" in the http://bugs.python.org/issue23320 opened by akira #23321: Crash in str.decode() with special error handler http://bugs.python.org/issue23321 opened by serhiy.storchaka #23322: parser module docs missing second example http://bugs.python.org/issue23322 opened by Devin Jeanpierre #23323: Issue with imaplib and append messages passing a tuple with fl http://bugs.python.org/issue23323 opened by Pilessio #23324: Nonblocking serial io using Arduino and Ubuntu 14.10 (Python 3 http://bugs.python.org/issue23324 opened by MrYsLab #23325: Turn SIG_DFL and SIG_IGN into functions http://bugs.python.org/issue23325 opened by serhiy.storchaka #23326: Remove redundant __ne__ implementations http://bugs.python.org/issue23326 opened by serhiy.storchaka #23327: zipimport to import from non-ascii pathname on Windows http://bugs.python.org/issue23327 opened by amswap #23328: urllib2 fails for proxy credentials that contain a '/' charact http://bugs.python.org/issue23328 opened by Andy.Reitz #23330: h2py.py regular expression missing http://bugs.python.org/issue23330 opened by Thomas.Roos #23331: Add non-interactive version of Bdb.runcall http://bugs.python.org/issue23331 opened by etanol #23332: datetime.isoformat() -> explicitly mark UTC string as such http://bugs.python.org/issue23332 opened by mirkovogt #23333: asyncio: add a new Protocol.connection_failed() method http://bugs.python.org/issue23333 opened by haypo #23336: Thread.LockType is misnamed http://bugs.python.org/issue23336 opened by cindykrafft #23337: Run python with restricted rights http://bugs.python.org/issue23337 opened by marcd #23338: PyErr_Format in ctypes uses invalid parameter http://bugs.python.org/issue23338 opened by mkato #23342: run() - unified high-level interface for subprocess http://bugs.python.org/issue23342 opened by takluyver #23344: Faster marshalling http://bugs.python.org/issue23344 opened by serhiy.storchaka #23345: test_ssl fails on OS X 10.10.2 with latest patch level of Open http://bugs.python.org/issue23345 opened by ned.deily #23346: shutil.rmtree doesn't work correctly on FreeBSD. http://bugs.python.org/issue23346 opened by negval #23348: distutils.LooseVersion fails to compare two valid versions http://bugs.python.org/issue23348 opened by maethor #23349: PyBuffer_ToContiguous() off-by-one error for non-contiguous bu http://bugs.python.org/issue23349 opened by rhansen #23350: Content-length is incorrect when request body is a list or tup http://bugs.python.org/issue23350 opened by demian.brecht #23351: socket.settimeout(5.0) does not have any effect http://bugs.python.org/issue23351 opened by piotrjurkiewicz #23352: PyBuffer_IsContiguous() sometimes returns wrong result if subo http://bugs.python.org/issue23352 opened by rhansen #23353: gnerator bug with exception: tstate->exc_value is not cleared http://bugs.python.org/issue23353 opened by haypo Most recent 15 issues with no replies (15) ========================================== #23349: PyBuffer_ToContiguous() off-by-one error for non-contiguous bu http://bugs.python.org/issue23349 #23344: Faster marshalling http://bugs.python.org/issue23344 #23336: Thread.LockType is misnamed http://bugs.python.org/issue23336 #23331: Add non-interactive version of Bdb.runcall http://bugs.python.org/issue23331 #23330: h2py.py regular expression missing http://bugs.python.org/issue23330 #23326: Remove redundant __ne__ implementations http://bugs.python.org/issue23326 #23325: Turn SIG_DFL and SIG_IGN into functions http://bugs.python.org/issue23325 #23319: Missing SWAP_INT??in I_set_sw http://bugs.python.org/issue23319 #23314: Disabling CRT asserts in debug build http://bugs.python.org/issue23314 #23310: MagicMock constructor configuration fails for magic methods http://bugs.python.org/issue23310 #23309: Hang on interpreter shutdown if daemon thread prints to stdout http://bugs.python.org/issue23309 #23291: Documentation about Py_Finalize(): Freeing objects http://bugs.python.org/issue23291 #23289: concurrent.futures.Executor.map is not equivalent to map. http://bugs.python.org/issue23289 #23287: ctypes.util.find_library needlessly call crle on Solaris http://bugs.python.org/issue23287 #23279: test_site/test_startup_imports fails when mpl_toolkit or logil http://bugs.python.org/issue23279 Most recent 15 issues waiting for review (15) ============================================= #23352: PyBuffer_IsContiguous() sometimes returns wrong result if subo http://bugs.python.org/issue23352 #23350: Content-length is incorrect when request body is a list or tup http://bugs.python.org/issue23350 #23349: PyBuffer_ToContiguous() off-by-one error for non-contiguous bu http://bugs.python.org/issue23349 #23344: Faster marshalling http://bugs.python.org/issue23344 #23342: run() - unified high-level interface for subprocess http://bugs.python.org/issue23342 #23338: PyErr_Format in ctypes uses invalid parameter http://bugs.python.org/issue23338 #23333: asyncio: add a new Protocol.connection_failed() method http://bugs.python.org/issue23333 #23330: h2py.py regular expression missing http://bugs.python.org/issue23330 #23327: zipimport to import from non-ascii pathname on Windows http://bugs.python.org/issue23327 #23326: Remove redundant __ne__ implementations http://bugs.python.org/issue23326 #23325: Turn SIG_DFL and SIG_IGN into functions http://bugs.python.org/issue23325 #23321: Crash in str.decode() with special error handler http://bugs.python.org/issue23321 #23319: Missing SWAP_INT??in I_set_sw http://bugs.python.org/issue23319 #23304: Unused Superclass in calendar.py http://bugs.python.org/issue23304 #23298: Add ArgumentParser.add_mutually_dependence_group http://bugs.python.org/issue23298 Top 10 most discussed issues (10) ================================= #2292: Missing *-unpacking generalizations http://bugs.python.org/issue2292 29 msgs #23332: datetime.isoformat() -> explicitly mark UTC string as such http://bugs.python.org/issue23332 16 msgs #17911: traceback: add a new thin class storing a traceback without st http://bugs.python.org/issue17911 15 msgs #23255: SimpleHTTPRequestHandler refactor for more extensible usage. http://bugs.python.org/issue23255 11 msgs #23284: Improve termcap detection in setup.py http://bugs.python.org/issue23284 11 msgs #23285: PEP 475 - EINTR handling http://bugs.python.org/issue23285 11 msgs #23316: Incorrect evaluation order of function arguments with *args http://bugs.python.org/issue23316 9 msgs #23333: asyncio: add a new Protocol.connection_failed() method http://bugs.python.org/issue23333 9 msgs #17797: Visual C++ 11.0 reports fileno(stdin) == 0 for non-console pro http://bugs.python.org/issue17797 7 msgs #23327: zipimport to import from non-ascii pathname on Windows http://bugs.python.org/issue23327 7 msgs Issues closed (41) ================== #7665: test_urllib2 and test_ntpath fail if path contains "\" http://bugs.python.org/issue7665 closed by serhiy.storchaka #8094: Multiprocessing infinite loop http://bugs.python.org/issue8094 closed by davin #8144: muliprocessing shutdown infinite loop http://bugs.python.org/issue8144 closed by davin #15101: multiprocessing pool finalizer can fail if triggered in backgr http://bugs.python.org/issue15101 closed by davin #18813: Speed up slice object processing http://bugs.python.org/issue18813 closed by scoder #19361: Specialize exceptions thrown by JSON parser http://bugs.python.org/issue19361 closed by serhiy.storchaka #19949: Explicitly skip or mask skipped/disabled tests in test_xpickle http://bugs.python.org/issue19949 closed by serhiy.storchaka #19996: httplib infinite read on invalid header http://bugs.python.org/issue19996 closed by python-dev #20188: ALPN support for TLS http://bugs.python.org/issue20188 closed by python-dev #20284: patch to implement PEP 461 (%-interpolation for bytes) http://bugs.python.org/issue20284 closed by ethan.furman #21408: delegation of `!=` to the right-hand side argument is not alwa http://bugs.python.org/issue21408 closed by serhiy.storchaka #21962: No timeout for asyncio.Event.wait() or asyncio.Condition.wait( http://bugs.python.org/issue21962 closed by haypo #22286: Allow backslashreplace error handler to be used on input http://bugs.python.org/issue22286 closed by serhiy.storchaka #22668: memoryview.format is corrupted due to dangling shared pointer http://bugs.python.org/issue22668 closed by python-dev #23046: asyncio.BaseEventLoop is documented, but only exported via asy http://bugs.python.org/issue23046 closed by haypo #23055: PyUnicode_FromFormatV crasher http://bugs.python.org/issue23055 closed by serhiy.storchaka #23094: Unpickler failing with PicklingError at frame end on readline http://bugs.python.org/issue23094 closed by serhiy.storchaka #23187: Segmentation fault, possibly asyncio related http://bugs.python.org/issue23187 closed by haypo #23191: fnmatch regex cache use is not threadsafe http://bugs.python.org/issue23191 closed by serhiy.storchaka #23202: pyvenv does not fail like documented when a venv already exist http://bugs.python.org/issue23202 closed by python-dev #23207: logging.basicConfig does not validate keyword arguments http://bugs.python.org/issue23207 closed by python-dev #23208: asyncio: add BaseEventLoop._current_handle (only used in debug http://bugs.python.org/issue23208 closed by haypo #23243: asyncio: emit ResourceWarning warnings if transports/event loo http://bugs.python.org/issue23243 closed by haypo #23253: Delay-load ShellExecute http://bugs.python.org/issue23253 closed by python-dev #23257: Update Windows build/setup instructions in devguide http://bugs.python.org/issue23257 closed by steve.dower #23268: Fix comparison of ipaddress classes http://bugs.python.org/issue23268 closed by serhiy.storchaka #23282: Slightly faster set lookup http://bugs.python.org/issue23282 closed by rhettinger #23286: A typo in the tutorial http://bugs.python.org/issue23286 closed by berker.peksag #23292: Enum doc suggestion http://bugs.python.org/issue23292 closed by mark #23305: RotatingFileHandler does not rotate if backupCount is 0 http://bugs.python.org/issue23305 closed by vinay.sajip #23307: python hangs on call to numpy.outer http://bugs.python.org/issue23307 closed by mark.dickinson #23313: Wrong complex variable being altered http://bugs.python.org/issue23313 closed by benjamin.peterson #23318: (compiled RegEx).split gives unexpected results if () in patte http://bugs.python.org/issue23318 closed by SilentGhost #23329: _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) http://bugs.python.org/issue23329 closed by python-dev #23334: http.client refactor http://bugs.python.org/issue23334 closed by demian.brecht #23335: _ssl.c cannot be compiled with older versions of OpenSSL http://bugs.python.org/issue23335 closed by python-dev #23339: dict_values should be comparable with a set http://bugs.python.org/issue23339 closed by r.david.murray #23340: uClibc C++ exceptions issue http://bugs.python.org/issue23340 closed by r.david.murray #23341: Issue parsing valid cookie http://bugs.python.org/issue23341 closed by dlamotte #23343: operator precedence table for `not x` has an operand, while th http://bugs.python.org/issue23343 closed by Hobson.Lane #23347: asyncio: fix and refactor creation of subprocess transports http://bugs.python.org/issue23347 closed by haypo From rymg19 at gmail.com Fri Jan 30 18:52:41 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 11:52:41 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: Is it possible at all to get a stack trace of the crash using gdb? Try the steps here . That way we can see where Python's own strdup function is getting called. On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton 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 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 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 > wrote: > >>> > >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum > >>> wrote: > >>>> > >>>> > >>>> What I see in the strace: > >>>> > >>>> ... load libpython3.4m.so.1.0 > >>>> ... load libm > >>>> ... open /dev/__properties__ and do something to it > >>>> (what?) > >>>> ... get current time > >>>> ... allocate memory > >>>> ... getuid > >>>> ... segfault > >>>> > >>>> That's not a lot to go on, but it doesn't look as if it has started > to > >>>> load modules yet. > >>>> > >>>> Does /dev/__properties__ ring a bell? Not to me. > >>> > >>> > >>> > >>> > >>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >>> is the code that works with that file. > >>> > >>> This explains it a bit (slides 24-29). Looks like something to do with > >>> interprocess communication. Likely has nothing to do with Python > itself. > >>> > >>> Maybe this would be useful? > >>> > >>>> > >>>> That stack trace would be really helpful. > >>>> > >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > >>>> 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 > > >>>>> 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 > > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> All, > >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android in > >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same > >>>>>>> configure > >>>>>>> options in the same environment, and modifying the setup.py as > >>>>>>> needed, > >>>>>>> the newly built binary throws a segfault when the > >>>>>>> generate-posix-vars > >>>>>>> portion of the build is reached...and when it is run as well (i.e. > >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) > >>>>>>> > >>>>>>> I took a strace of ./python, however I'm a bit lost when reviewing > >>>>>>> it. > >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 works > but > >>>>>>> 3.x throws a segfault? > >>>>>>> > >>>>>>> Thanks in advance, > >>>>>>> Cyd > >>>>>>> ________________________________ > >>>>>>> > >>>>>>> Python-Dev mailing list > >>>>>>> > >>>>>>> Python-Dev at python.org > >>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >>>>>>> Unsubscribe: > >>>>>>> > >>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> --Guido van Rossum (python.org/~guido) > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> --Guido van Rossum (python.org/~guido) > >>>> > >>>> ________________________________ > >>>> > >>>> Python-Dev mailing list > >>>> Python-Dev at python.org > >>>> https://mail.python.org/mailman/listinfo/python-dev > >>>> Unsubscribe: > >>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Ryan > >>> If anybody ever asks me why I prefer C++ to C, my answer will be > simple: > >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that > was > >>> nul-terminated." > >>> Personal reality distortion fields are immune to contradictory > evidence. > >>> - > >>> srean > >>> Check out my website: http://kirbyfan64.github.io/ > > > > > > -- > > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Check out my website: http://kirbyfan64.github.io/ > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Fri Jan 30 18:53:13 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 11:53:13 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 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 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 wrote: >>>>> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >>>>> wrote: >>>>>> >>>>>> >>>>>> What I see in the strace: >>>>>> >>>>>> ... load libpython3.4m.so.1.0 >>>>>> ... load libm >>>>>> ... open /dev/__properties__ and do something to it >>>>>> (what?) >>>>>> ... get current time >>>>>> ... allocate memory >>>>>> ... getuid >>>>>> ... segfault >>>>>> >>>>>> That's not a lot to go on, but it doesn't look as if it has started to >>>>>> load modules yet. >>>>>> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >>>>> >>>>> >>>>> >>>>> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>>>> is the code that works with that file. >>>>> >>>>> This explains it a bit (slides 24-29). Looks like something to do with >>>>> interprocess communication. Likely has nothing to do with Python itself. >>>>> >>>>> Maybe this would be useful? >>>>> >>>>>> >>>>>> That stack trace would be really helpful. >>>>>> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>>>>> 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 >>>>>>> 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 >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> All, >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android in >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >>>>>>>>> configure >>>>>>>>> options in the same environment, and modifying the setup.py as >>>>>>>>> needed, >>>>>>>>> the newly built binary throws a segfault when the >>>>>>>>> generate-posix-vars >>>>>>>>> portion of the build is reached...and when it is run as well (i.e. >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >>>>>>>>> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when reviewing >>>>>>>>> it. >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 works but >>>>>>>>> 3.x throws a segfault? >>>>>>>>> >>>>>>>>> Thanks in advance, >>>>>>>>> Cyd >>>>>>>>> ________________________________ >>>>>>>>> >>>>>>>>> Python-Dev mailing list >>>>>>>>> >>>>>>>>> Python-Dev at python.org >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>>>>> Unsubscribe: >>>>>>>>> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> --Guido van Rossum (python.org/~guido) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --Guido van Rossum (python.org/~guido) >>>>>> >>>>>> ________________________________ >>>>>> >>>>>> Python-Dev mailing list >>>>>> Python-Dev at python.org >>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>> Unsubscribe: >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Ryan >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be simple: >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >>>>> nul-terminated." >>>>> Personal reality distortion fields are immune to contradictory evidence. >>>>> - >>>>> srean >>>>> Check out my website: http://kirbyfan64.github.io/ >>> >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> Check out my website: http://kirbyfan64.github.io/ From rymg19 at gmail.com Fri Jan 30 18:56:34 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 11:56:34 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 > 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 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 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 > wrote: > >>>>> > >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum < > guido at python.org> > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> What I see in the strace: > >>>>>> > >>>>>> ... load libpython3.4m.so.1.0 > >>>>>> ... load libm > >>>>>> ... open /dev/__properties__ and do something to it > >>>>>> (what?) > >>>>>> ... get current time > >>>>>> ... allocate memory > >>>>>> ... getuid > >>>>>> ... segfault > >>>>>> > >>>>>> That's not a lot to go on, but it doesn't look as if it has > started to > >>>>>> load modules yet. > >>>>>> > >>>>>> Does /dev/__properties__ ring a bell? Not to me. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >>>>> is the code that works with that file. > >>>>> > >>>>> This explains it a bit (slides 24-29). Looks like something to do > with > >>>>> interprocess communication. Likely has nothing to do with Python > itself. > >>>>> > >>>>> Maybe this would be useful? > >>>>> > >>>>>> > >>>>>> That stack trace would be really helpful. > >>>>>> > >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > > >>>>>> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Apologies...I'm not sure what a stack track is, but I do have the > >>>>>>> strace. Nearest I can tell, it happens due to an open call, > though I > >>>>>>> am probably wrong. > >>>>>>> Attaching the strace output to this email. I'm going to head > back to > >>>>>>> the documentation and to back out of some Android-related changes > in > >>>>>>> _localemodule.c > >>>>>>> > >>>>>>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum < > guido at python.org> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> There could be a million differences relevant (unicode, ints, > ...). > >>>>>>>> Perhaps > >>>>>>>> the importlib bootstrap is failing. Perhaps the dynamic loading > code > >>>>>>>> changed. Did you get a stack track? (IIRC strace shows a syscall > >>>>>>>> trace > >>>>>>>> -- > >>>>>>>> also useful, but doesn't tell you precisely how > >>>>>>>> it segfaulted.) > >>>>>>>> > >>>>>>>> On Wed, Jan 28, 2015 at 6:43 AM, Cyd Haselton < > chaselton at gmail.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> All, > >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android > in > >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same > >>>>>>>>> configure > >>>>>>>>> options in the same environment, and modifying the setup.py as > >>>>>>>>> needed, > >>>>>>>>> the newly built binary throws a segfault when the > >>>>>>>>> generate-posix-vars > >>>>>>>>> portion of the build is reached...and when it is run as well > (i.e. > >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) > >>>>>>>>> > >>>>>>>>> I took a strace of ./python, however I'm a bit lost when > reviewing > >>>>>>>>> it. > >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 > works but > >>>>>>>>> 3.x throws a segfault? > >>>>>>>>> > >>>>>>>>> Thanks in advance, > >>>>>>>>> Cyd > >>>>>>>>> ________________________________ > >>>>>>>>> > >>>>>>>>> Python-Dev mailing list > >>>>>>>>> > >>>>>>>>> Python-Dev at python.org > >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >>>>>>>>> Unsubscribe: > >>>>>>>>> > >>>>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> --Guido van Rossum (python.org/~guido) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> --Guido van Rossum (python.org/~guido) > >>>>>> > >>>>>> ________________________________ > >>>>>> > >>>>>> Python-Dev mailing list > >>>>>> Python-Dev at python.org > >>>>>> https://mail.python.org/mailman/listinfo/python-dev > >>>>>> Unsubscribe: > >>>>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Ryan > >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be > simple: > >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think > that was > >>>>> nul-terminated." > >>>>> Personal reality distortion fields are immune to contradictory > evidence. > >>>>> - > >>>>> srean > >>>>> Check out my website: http://kirbyfan64.github.io/ > >>> > >>> > >>> -- > >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >>> Check out my website: http://kirbyfan64.github.io/ > -- Ryan If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated." Personal reality distortion fields are immune to contradictory evidence. - srean Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Fri Jan 30 19:00:32 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 12:00:32 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: I don't have gdb on device; does the following tell you where Python's strdup is called? >> _PyMem_RawStrdup >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: > Is it possible at all to get a stack trace of the crash using gdb? Try the > steps here. > > That way we can see where Python's own strdup function is getting called. > > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton 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 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 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 >> >> wrote: >> >>> >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >>> wrote: >> >>>> >> >>>> >> >>>> What I see in the strace: >> >>>> >> >>>> ... load libpython3.4m.so.1.0 >> >>>> ... load libm >> >>>> ... open /dev/__properties__ and do something to it >> >>>> (what?) >> >>>> ... get current time >> >>>> ... allocate memory >> >>>> ... getuid >> >>>> ... segfault >> >>>> >> >>>> That's not a lot to go on, but it doesn't look as if it has started >> >>>> to >> >>>> load modules yet. >> >>>> >> >>>> Does /dev/__properties__ ring a bell? Not to me. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >>> is the code that works with that file. >> >>> >> >>> This explains it a bit (slides 24-29). Looks like something to do >> >>> with >> >>> interprocess communication. Likely has nothing to do with Python >> >>> itself. >> >>> >> >>> Maybe this would be useful? >> >>> >> >>>> >> >>>> That stack trace would be really helpful. >> >>>> >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >>>> 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 >> >>>>> >> >>>>> 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 >> >>>>>> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> All, >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android in >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >>>>>>> configure >> >>>>>>> options in the same environment, and modifying the setup.py as >> >>>>>>> needed, >> >>>>>>> the newly built binary throws a segfault when the >> >>>>>>> generate-posix-vars >> >>>>>>> portion of the build is reached...and when it is run as well >> >>>>>>> (i.e. >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >>>>>>> >> >>>>>>> I took a strace of ./python, however I'm a bit lost when >> >>>>>>> reviewing >> >>>>>>> it. >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 works >> >>>>>>> but >> >>>>>>> 3.x throws a segfault? >> >>>>>>> >> >>>>>>> Thanks in advance, >> >>>>>>> Cyd >> >>>>>>> ________________________________ >> >>>>>>> >> >>>>>>> Python-Dev mailing list >> >>>>>>> >> >>>>>>> Python-Dev at python.org >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >>>>>>> Unsubscribe: >> >>>>>>> >> >>>>>>> >> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> --Guido van Rossum (python.org/~guido) >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> --Guido van Rossum (python.org/~guido) >> >>>> >> >>>> ________________________________ >> >>>> >> >>>> Python-Dev mailing list >> >>>> Python-Dev at python.org >> >>>> https://mail.python.org/mailman/listinfo/python-dev >> >>>> Unsubscribe: >> >>>> >> >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Ryan >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >>> simple: >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that >> >>> was >> >>> nul-terminated." >> >>> Personal reality distortion fields are immune to contradictory >> >>> evidence. >> >>> - >> >>> srean >> >>> Check out my website: http://kirbyfan64.github.io/ >> > >> > >> > -- >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> > Check out my website: http://kirbyfan64.github.io/ > > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ From rymg19 at gmail.com Fri Jan 30 19:04:41 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 12:04:41 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: No... ...but I think I found the issue with grep. Try applying the attached patch to the Python/frozenmain.c. It comments out the locale handling. It seems that Python always calls its strdup function on the locale string. On Android, this can apparently be null (as seen in the bug report you linked to). On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton wrote: > I don't have gdb on device; does the following tell you where Python's > strdup is called? > > >> _PyMem_RawStrdup > >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 > > On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: > > Is it possible at all to get a stack trace of the crash using gdb? Try > the > > steps here. > > > > That way we can see where Python's own strdup function is getting called. > > > > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton > 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 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 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 > >> >> wrote: > >> >>> > >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum < > guido at python.org> > >> >>> wrote: > >> >>>> > >> >>>> > >> >>>> What I see in the strace: > >> >>>> > >> >>>> ... load libpython3.4m.so.1.0 > >> >>>> ... load libm > >> >>>> ... open /dev/__properties__ and do something to it > >> >>>> (what?) > >> >>>> ... get current time > >> >>>> ... allocate memory > >> >>>> ... getuid > >> >>>> ... segfault > >> >>>> > >> >>>> That's not a lot to go on, but it doesn't look as if it has > started > >> >>>> to > >> >>>> load modules yet. > >> >>>> > >> >>>> Does /dev/__properties__ ring a bell? Not to me. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >> >>> is the code that works with that file. > >> >>> > >> >>> This explains it a bit (slides 24-29). Looks like something to do > >> >>> with > >> >>> interprocess communication. Likely has nothing to do with Python > >> >>> itself. > >> >>> > >> >>> Maybe this would be useful? > >> >>> > >> >>>> > >> >>>> That stack trace would be really helpful. > >> >>>> > >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton < > chaselton at gmail.com> > >> >>>> wrote: > >> >>>>> > >> >>>>> > >> >>>>> Apologies...I'm not sure what a stack track is, but I do have the > >> >>>>> strace. Nearest I can tell, it happens due to an open call, > though > >> >>>>> I > >> >>>>> am probably wrong. > >> >>>>> Attaching the strace output to this email. I'm going to head > back > >> >>>>> to > >> >>>>> the documentation and to back out of some Android-related changes > >> >>>>> in > >> >>>>> _localemodule.c > >> >>>>> > >> >>>>> On Wed, Jan 28, 2015 at 9:43 AM, Guido van Rossum > >> >>>>> > >> >>>>> 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 > >> >>>>>> > >> >>>>>> wrote: > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> All, > >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android > in > >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same > >> >>>>>>> configure > >> >>>>>>> options in the same environment, and modifying the setup.py as > >> >>>>>>> needed, > >> >>>>>>> the newly built binary throws a segfault when the > >> >>>>>>> generate-posix-vars > >> >>>>>>> portion of the build is reached...and when it is run as well > >> >>>>>>> (i.e. > >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) > >> >>>>>>> > >> >>>>>>> I took a strace of ./python, however I'm a bit lost when > >> >>>>>>> reviewing > >> >>>>>>> it. > >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 > works > >> >>>>>>> but > >> >>>>>>> 3.x throws a segfault? > >> >>>>>>> > >> >>>>>>> Thanks in advance, > >> >>>>>>> Cyd > >> >>>>>>> ________________________________ > >> >>>>>>> > >> >>>>>>> Python-Dev mailing list > >> >>>>>>> > >> >>>>>>> Python-Dev at python.org > >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >>>>>>> Unsubscribe: > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> --Guido van Rossum (python.org/~guido) > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> -- > >> >>>> --Guido van Rossum (python.org/~guido) > >> >>>> > >> >>>> ________________________________ > >> >>>> > >> >>>> Python-Dev mailing list > >> >>>> Python-Dev at python.org > >> >>>> https://mail.python.org/mailman/listinfo/python-dev > >> >>>> Unsubscribe: > >> >>>> > >> >>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> -- > >> >>> Ryan > >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be > >> >>> simple: > >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think > that > >> >>> was > >> >>> nul-terminated." > >> >>> Personal reality distortion fields are immune to contradictory > >> >>> evidence. > >> >>> - > >> >>> srean > >> >>> Check out my website: http://kirbyfan64.github.io/ > >> > > >> > > >> > -- > >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >> > Check out my website: http://kirbyfan64.github.io/ > > > > > > > > > > -- > > Ryan > > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > > nul-terminated." > > Personal reality distortion fields are immune to contradictory evidence. > - > > srean > > Check out my website: http://kirbyfan64.github.io/ > -- 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 22c22 < char *oldloc = NULL; --- > /*char *oldloc = NULL;*/ 47c47 < oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL)); --- > /*oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL)); 53c53 < setlocale(LC_ALL, ""); --- > setlocale(LC_ALL, "");*/ 64c64 < setlocale(LC_ALL, oldloc); --- > /*setlocale(LC_ALL, oldloc); 66c66 < oldloc = NULL; --- > oldloc = NULL;*/ From chaselton at gmail.com Fri Jan 30 19:09:01 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 12:09:01 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 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 >> > 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 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 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 >> >>>> wrote: >> >>>>> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >>>>> >> >>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>> What I see in the strace: >> >>>>>> >> >>>>>> ... load libpython3.4m.so.1.0 >> >>>>>> ... load libm >> >>>>>> ... open /dev/__properties__ and do something to it >> >>>>>> (what?) >> >>>>>> ... get current time >> >>>>>> ... allocate memory >> >>>>>> ... getuid >> >>>>>> ... segfault >> >>>>>> >> >>>>>> That's not a lot to go on, but it doesn't look as if it has >> >>>>>> started to >> >>>>>> load modules yet. >> >>>>>> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >>>>> is the code that works with that file. >> >>>>> >> >>>>> This explains it a bit (slides 24-29). Looks like something to do >> >>>>> with >> >>>>> interprocess communication. Likely has nothing to do with Python >> >>>>> itself. >> >>>>> >> >>>>> Maybe this would be useful? >> >>>>> >> >>>>>> >> >>>>>> That stack trace would be really helpful. >> >>>>>> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >>>>>> >> >>>>>> 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 >> >>>>>>> >> >>>>>>> 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 >> >>>>>>>> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> All, >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android >> >>>>>>>>> in >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >>>>>>>>> configure >> >>>>>>>>> options in the same environment, and modifying the setup.py as >> >>>>>>>>> needed, >> >>>>>>>>> the newly built binary throws a segfault when the >> >>>>>>>>> generate-posix-vars >> >>>>>>>>> portion of the build is reached...and when it is run as well >> >>>>>>>>> (i.e. >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >>>>>>>>> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when >> >>>>>>>>> reviewing >> >>>>>>>>> it. >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >> >>>>>>>>> works but >> >>>>>>>>> 3.x throws a segfault? >> >>>>>>>>> >> >>>>>>>>> Thanks in advance, >> >>>>>>>>> Cyd >> >>>>>>>>> ________________________________ >> >>>>>>>>> >> >>>>>>>>> Python-Dev mailing list >> >>>>>>>>> >> >>>>>>>>> Python-Dev at python.org >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >>>>>>>>> Unsubscribe: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> --Guido van Rossum (python.org/~guido) >> >>>>>> >> >>>>>> ________________________________ >> >>>>>> >> >>>>>> Python-Dev mailing list >> >>>>>> Python-Dev at python.org >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >>>>>> Unsubscribe: >> >>>>>> >> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Ryan >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >>>>> simple: >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >>>>> that was >> >>>>> nul-terminated." >> >>>>> Personal reality distortion fields are immune to contradictory >> >>>>> evidence. >> >>>>> - >> >>>>> srean >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >>> >> >>> >> >>> -- >> >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >>> Check out my website: http://kirbyfan64.github.io/ > > > > > -- > Ryan > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > nul-terminated." > Personal reality distortion fields are immune to contradictory evidence. - > srean > Check out my website: http://kirbyfan64.github.io/ From rymg19 at gmail.com Fri Jan 30 19:10:57 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 12:10:57 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 > 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 > 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 > >> > 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 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 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 > >> >>>> wrote: > >> >>>>> > >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum > >> >>>>> > >> >>>>> wrote: > >> >>>>>> > >> >>>>>> > >> >>>>>> What I see in the strace: > >> >>>>>> > >> >>>>>> ... load libpython3.4m.so.1.0 > >> >>>>>> ... load libm > >> >>>>>> ... open /dev/__properties__ and do something to it > >> >>>>>> (what?) > >> >>>>>> ... get current time > >> >>>>>> ... allocate memory > >> >>>>>> ... getuid > >> >>>>>> ... segfault > >> >>>>>> > >> >>>>>> That's not a lot to go on, but it doesn't look as if it has > >> >>>>>> started to > >> >>>>>> load modules yet. > >> >>>>>> > >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >> >>>>> is the code that works with that file. > >> >>>>> > >> >>>>> This explains it a bit (slides 24-29). Looks like something to do > >> >>>>> with > >> >>>>> interprocess communication. Likely has nothing to do with Python > >> >>>>> itself. > >> >>>>> > >> >>>>> Maybe this would be useful? > >> >>>>> > >> >>>>>> > >> >>>>>> That stack trace would be really helpful. > >> >>>>>> > >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > >> >>>>>> > >> >>>>>> 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 > >> >>>>>>> > >> >>>>>>> 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 > >> >>>>>>>> > >> >>>>>>>> wrote: > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> All, > >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to > Android > >> >>>>>>>>> in > >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same > >> >>>>>>>>> configure > >> >>>>>>>>> options in the same environment, and modifying the setup.py > as > >> >>>>>>>>> needed, > >> >>>>>>>>> the newly built binary throws a segfault when the > >> >>>>>>>>> generate-posix-vars > >> >>>>>>>>> portion of the build is reached...and when it is run as well > >> >>>>>>>>> (i.e. > >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) > >> >>>>>>>>> > >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when > >> >>>>>>>>> reviewing > >> >>>>>>>>> it. > >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 > >> >>>>>>>>> works but > >> >>>>>>>>> 3.x throws a segfault? > >> >>>>>>>>> > >> >>>>>>>>> Thanks in advance, > >> >>>>>>>>> Cyd > >> >>>>>>>>> ________________________________ > >> >>>>>>>>> > >> >>>>>>>>> Python-Dev mailing list > >> >>>>>>>>> > >> >>>>>>>>> Python-Dev at python.org > >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >>>>>>>>> Unsubscribe: > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> > >> >>>>>>>> -- > >> >>>>>>>> --Guido van Rossum (python.org/~guido) > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> > >> >>>>>> -- > >> >>>>>> --Guido van Rossum (python.org/~guido) > >> >>>>>> > >> >>>>>> ________________________________ > >> >>>>>> > >> >>>>>> Python-Dev mailing list > >> >>>>>> Python-Dev at python.org > >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >>>>>> Unsubscribe: > >> >>>>>> > >> >>>>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> Ryan > >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be > >> >>>>> simple: > >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think > >> >>>>> that was > >> >>>>> nul-terminated." > >> >>>>> Personal reality distortion fields are immune to contradictory > >> >>>>> evidence. > >> >>>>> - > >> >>>>> srean > >> >>>>> Check out my website: http://kirbyfan64.github.io/ > >> >>> > >> >>> > >> >>> -- > >> >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. > >> >>> Check out my website: http://kirbyfan64.github.io/ > > > > > > > > > > -- > > Ryan > > If anybody ever asks me why I prefer C++ to C, my answer will be simple: > > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was > > nul-terminated." > > Personal reality distortion fields are immune to contradictory evidence. > - > > srean > > Check out my website: http://kirbyfan64.github.io/ > -- 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.stinner at gmail.com Fri Jan 30 21:04:16 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 30 Jan 2015 21:04:16 +0100 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: Android provides a minimal support of locales. Most functions return a fake result, do nothing. I'm not sure that it supports any codec. To support Android, we may force UTF-8 for the filesystem encoding, as done on Mac OS X. Victor 2015-01-30 19:04 GMT+01:00 Ryan Gonzalez : > No... > > ...but I think I found the issue with grep. Try applying the attached patch > to the Python/frozenmain.c. It comments out the locale handling. > > It seems that Python always calls its strdup function on the locale string. > On Android, this can apparently be null (as seen in the bug report you > linked to). > > On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton wrote: >> >> I don't have gdb on device; does the following tell you where Python's >> strdup is called? >> >> >> _PyMem_RawStrdup >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >> >> On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: >> > Is it possible at all to get a stack trace of the crash using gdb? Try >> > the >> > steps here. >> > >> > That way we can see where Python's own strdup function is getting >> > called. >> > >> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton >> > 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 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 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 >> >> >> wrote: >> >> >>> >> >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >>> >> >> >>> wrote: >> >> >>>> >> >> >>>> >> >> >>>> What I see in the strace: >> >> >>>> >> >> >>>> ... load libpython3.4m.so.1.0 >> >> >>>> ... load libm >> >> >>>> ... open /dev/__properties__ and do something to it >> >> >>>> (what?) >> >> >>>> ... get current time >> >> >>>> ... allocate memory >> >> >>>> ... getuid >> >> >>>> ... segfault >> >> >>>> >> >> >>>> That's not a lot to go on, but it doesn't look as if it has >> >> >>>> started >> >> >>>> to >> >> >>>> load modules yet. >> >> >>>> >> >> >>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >>> is the code that works with that file. >> >> >>> >> >> >>> This explains it a bit (slides 24-29). Looks like something to do >> >> >>> with >> >> >>> interprocess communication. Likely has nothing to do with Python >> >> >>> itself. >> >> >>> >> >> >>> Maybe this would be useful? >> >> >>> >> >> >>>> >> >> >>>> That stack trace would be really helpful. >> >> >>>> >> >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >>>> >> >> >>>> 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 >> >> >>>>> >> >> >>>>> 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 >> >> >>>>>> >> >> >>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> All, >> >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android >> >> >>>>>>> in >> >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >> >>>>>>> configure >> >> >>>>>>> options in the same environment, and modifying the setup.py as >> >> >>>>>>> needed, >> >> >>>>>>> the newly built binary throws a segfault when the >> >> >>>>>>> generate-posix-vars >> >> >>>>>>> portion of the build is reached...and when it is run as well >> >> >>>>>>> (i.e. >> >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> >>>>>>> >> >> >>>>>>> I took a strace of ./python, however I'm a bit lost when >> >> >>>>>>> reviewing >> >> >>>>>>> it. >> >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >> >> >>>>>>> works >> >> >>>>>>> but >> >> >>>>>>> 3.x throws a segfault? >> >> >>>>>>> >> >> >>>>>>> Thanks in advance, >> >> >>>>>>> Cyd >> >> >>>>>>> ________________________________ >> >> >>>>>>> >> >> >>>>>>> Python-Dev mailing list >> >> >>>>>>> >> >> >>>>>>> Python-Dev at python.org >> >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>>> Unsubscribe: >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> >> >> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> -- >> >> >>>> --Guido van Rossum (python.org/~guido) >> >> >>>> >> >> >>>> ________________________________ >> >> >>>> >> >> >>>> Python-Dev mailing list >> >> >>>> Python-Dev at python.org >> >> >>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>> Unsubscribe: >> >> >>>> >> >> >>>> >> >> >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Ryan >> >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >> >>> simple: >> >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >>> that >> >> >>> was >> >> >>> nul-terminated." >> >> >>> Personal reality distortion fields are immune to contradictory >> >> >>> evidence. >> >> >>> - >> >> >>> srean >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> > >> >> > >> >> > -- >> >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> > Check out my website: http://kirbyfan64.github.io/ >> > >> > >> > >> > >> > -- >> > Ryan >> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >> > nul-terminated." >> > Personal reality distortion fields are immune to contradictory evidence. >> > - >> > srean >> > Check out my website: http://kirbyfan64.github.io/ > > > > > -- > 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/ > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > From victor.stinner at gmail.com Fri Jan 30 21:07:07 2015 From: victor.stinner at gmail.com (Victor Stinner) Date: Fri, 30 Jan 2015 21:07:07 +0100 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: Oh, I found my old patch to force UTF-8 on Android. I didn't test it: see attached file. It would be nice to start a wiki page to collect all informations on the Python port to Android. Victor 2015-01-30 21:04 GMT+01:00 Victor Stinner : > Android provides a minimal support of locales. Most functions return a > fake result, do nothing. I'm not sure that it supports any codec. To > support Android, we may force UTF-8 for the filesystem encoding, as > done on Mac OS X. > > Victor > > 2015-01-30 19:04 GMT+01:00 Ryan Gonzalez : >> No... >> >> ...but I think I found the issue with grep. Try applying the attached patch >> to the Python/frozenmain.c. It comments out the locale handling. >> >> It seems that Python always calls its strdup function on the locale string. >> On Android, this can apparently be null (as seen in the bug report you >> linked to). >> >> On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton wrote: >>> >>> I don't have gdb on device; does the following tell you where Python's >>> strdup is called? >>> >>> >> _PyMem_RawStrdup >>> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >>> >>> On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: >>> > Is it possible at all to get a stack trace of the crash using gdb? Try >>> > the >>> > steps here. >>> > >>> > That way we can see where Python's own strdup function is getting >>> > called. >>> > >>> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton >>> > 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 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 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 >>> >> >> wrote: >>> >> >>> >>> >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >>> >> >>> >>> >> >>> wrote: >>> >> >>>> >>> >> >>>> >>> >> >>>> What I see in the strace: >>> >> >>>> >>> >> >>>> ... load libpython3.4m.so.1.0 >>> >> >>>> ... load libm >>> >> >>>> ... open /dev/__properties__ and do something to it >>> >> >>>> (what?) >>> >> >>>> ... get current time >>> >> >>>> ... allocate memory >>> >> >>>> ... getuid >>> >> >>>> ... segfault >>> >> >>>> >>> >> >>>> That's not a lot to go on, but it doesn't look as if it has >>> >> >>>> started >>> >> >>>> to >>> >> >>>> load modules yet. >>> >> >>>> >>> >> >>>> Does /dev/__properties__ ring a bell? Not to me. >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>> >> >>> is the code that works with that file. >>> >> >>> >>> >> >>> This explains it a bit (slides 24-29). Looks like something to do >>> >> >>> with >>> >> >>> interprocess communication. Likely has nothing to do with Python >>> >> >>> itself. >>> >> >>> >>> >> >>> Maybe this would be useful? >>> >> >>> >>> >> >>>> >>> >> >>>> That stack trace would be really helpful. >>> >> >>>> >>> >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>> >> >>>> >>> >> >>>> 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 >>> >> >>>>> >>> >> >>>>> 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 >>> >> >>>>>> >>> >> >>>>>> wrote: >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> All, >>> >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android >>> >> >>>>>>> in >>> >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >>> >> >>>>>>> configure >>> >> >>>>>>> options in the same environment, and modifying the setup.py as >>> >> >>>>>>> needed, >>> >> >>>>>>> the newly built binary throws a segfault when the >>> >> >>>>>>> generate-posix-vars >>> >> >>>>>>> portion of the build is reached...and when it is run as well >>> >> >>>>>>> (i.e. >>> >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >>> >> >>>>>>> >>> >> >>>>>>> I took a strace of ./python, however I'm a bit lost when >>> >> >>>>>>> reviewing >>> >> >>>>>>> it. >>> >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >>> >> >>>>>>> works >>> >> >>>>>>> but >>> >> >>>>>>> 3.x throws a segfault? >>> >> >>>>>>> >>> >> >>>>>>> Thanks in advance, >>> >> >>>>>>> Cyd >>> >> >>>>>>> ________________________________ >>> >> >>>>>>> >>> >> >>>>>>> Python-Dev mailing list >>> >> >>>>>>> >>> >> >>>>>>> Python-Dev at python.org >>> >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >>> >> >>>>>>> Unsubscribe: >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> >>> >> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> >>> >> >>>>>> -- >>> >> >>>>>> --Guido van Rossum (python.org/~guido) >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> >>> >> >>>> -- >>> >> >>>> --Guido van Rossum (python.org/~guido) >>> >> >>>> >>> >> >>>> ________________________________ >>> >> >>>> >>> >> >>>> Python-Dev mailing list >>> >> >>>> Python-Dev at python.org >>> >> >>>> https://mail.python.org/mailman/listinfo/python-dev >>> >> >>>> Unsubscribe: >>> >> >>>> >>> >> >>>> >>> >> >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> -- >>> >> >>> Ryan >>> >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be >>> >> >>> simple: >>> >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >>> >> >>> that >>> >> >>> was >>> >> >>> nul-terminated." >>> >> >>> Personal reality distortion fields are immune to contradictory >>> >> >>> evidence. >>> >> >>> - >>> >> >>> srean >>> >> >>> Check out my website: http://kirbyfan64.github.io/ >>> >> > >>> >> > >>> >> > -- >>> >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> >> > Check out my website: http://kirbyfan64.github.io/ >>> > >>> > >>> > >>> > >>> > -- >>> > Ryan >>> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >>> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >>> > nul-terminated." >>> > Personal reality distortion fields are immune to contradictory evidence. >>> > - >>> > srean >>> > Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> -- >> 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/ >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >> -------------- next part -------------- A non-text attachment was scrubbed... Name: android_utf8-2.patch Type: text/x-patch Size: 4241 bytes Desc: not available URL: From chaselton at gmail.com Fri Jan 30 19:34:18 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 12:34:18 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: Ok...that makes sense.. apologies I do not do a lot of debugging. My goal was to get Python (then spidermonkey) on my device then start learning languages where i'd need to learn debugging. Tried patch, see my reply, agree about Android's locale...at least where native codeis concerned On Fri, Jan 30, 2015 at 12:10 PM, Ryan Gonzalez 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 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 >> > 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 >> >> 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 >> >> > 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 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 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 >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> What I see in the strace: >> >> >>>>>> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >>>>>> ... load libm >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >>>>>> (what?) >> >> >>>>>> ... get current time >> >> >>>>>> ... allocate memory >> >> >>>>>> ... getuid >> >> >>>>>> ... segfault >> >> >>>>>> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if it has >> >> >>>>>> started to >> >> >>>>>> load modules yet. >> >> >>>>>> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >>>>> is the code that works with that file. >> >> >>>>> >> >> >>>>> This explains it a bit (slides 24-29). Looks like something to >> >> >>>>> do >> >> >>>>> with >> >> >>>>> interprocess communication. Likely has nothing to do with Python >> >> >>>>> itself. >> >> >>>>> >> >> >>>>> Maybe this would be useful? >> >> >>>>> >> >> >>>>>> >> >> >>>>>> That stack trace would be really helpful. >> >> >>>>>> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >>>>>> >> >> >>>>>> 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 >> >> >>>>>>> >> >> >>>>>>> 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 >> >> >>>>>>>> >> >> >>>>>>>> wrote: >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> All, >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to >> >> >>>>>>>>> Android >> >> >>>>>>>>> in >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >> >>>>>>>>> configure >> >> >>>>>>>>> options in the same environment, and modifying the setup.py >> >> >>>>>>>>> as >> >> >>>>>>>>> needed, >> >> >>>>>>>>> the newly built binary throws a segfault when the >> >> >>>>>>>>> generate-posix-vars >> >> >>>>>>>>> portion of the build is reached...and when it is run as well >> >> >>>>>>>>> (i.e. >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> >>>>>>>>> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when >> >> >>>>>>>>> reviewing >> >> >>>>>>>>> it. >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >> >> >>>>>>>>> works but >> >> >>>>>>>>> 3.x throws a segfault? >> >> >>>>>>>>> >> >> >>>>>>>>> Thanks in advance, >> >> >>>>>>>>> Cyd >> >> >>>>>>>>> ________________________________ >> >> >>>>>>>>> >> >> >>>>>>>>> Python-Dev mailing list >> >> >>>>>>>>> >> >> >>>>>>>>> Python-Dev at python.org >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>>>>> Unsubscribe: >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> -- >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>>>> >> >> >>>>>> ________________________________ >> >> >>>>>> >> >> >>>>>> Python-Dev mailing list >> >> >>>>>> Python-Dev at python.org >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>> Unsubscribe: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Ryan >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >> >>>>> simple: >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >>>>> that was >> >> >>>>> nul-terminated." >> >> >>>>> Personal reality distortion fields are immune to contradictory >> >> >>>>> evidence. >> >> >>>>> - >> >> >>>>> srean >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> > >> > >> > >> > >> > -- >> > Ryan >> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >> > nul-terminated." >> > Personal reality distortion fields are immune to contradictory evidence. >> > - >> > srean >> > Check out my website: http://kirbyfan64.github.io/ > > > > > -- > 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/ From chaselton at gmail.com Fri Jan 30 19:58:28 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 12:58:28 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 >> > 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 >> >> 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 >> >> > 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 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 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 >> >> >>>> wrote: >> >> >>>>> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >>>>> >> >> >>>>> wrote: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> What I see in the strace: >> >> >>>>>> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >>>>>> ... load libm >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >>>>>> (what?) >> >> >>>>>> ... get current time >> >> >>>>>> ... allocate memory >> >> >>>>>> ... getuid >> >> >>>>>> ... segfault >> >> >>>>>> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if it has >> >> >>>>>> started to >> >> >>>>>> load modules yet. >> >> >>>>>> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >>>>> is the code that works with that file. >> >> >>>>> >> >> >>>>> This explains it a bit (slides 24-29). Looks like something to >> >> >>>>> do >> >> >>>>> with >> >> >>>>> interprocess communication. Likely has nothing to do with Python >> >> >>>>> itself. >> >> >>>>> >> >> >>>>> Maybe this would be useful? >> >> >>>>> >> >> >>>>>> >> >> >>>>>> That stack trace would be really helpful. >> >> >>>>>> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >>>>>> >> >> >>>>>> 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 >> >> >>>>>>> >> >> >>>>>>> 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 >> >> >>>>>>>> >> >> >>>>>>>> wrote: >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> All, >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to >> >> >>>>>>>>> Android >> >> >>>>>>>>> in >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >> >> >>>>>>>>> configure >> >> >>>>>>>>> options in the same environment, and modifying the setup.py >> >> >>>>>>>>> as >> >> >>>>>>>>> needed, >> >> >>>>>>>>> the newly built binary throws a segfault when the >> >> >>>>>>>>> generate-posix-vars >> >> >>>>>>>>> portion of the build is reached...and when it is run as well >> >> >>>>>>>>> (i.e. >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >> >> >>>>>>>>> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when >> >> >>>>>>>>> reviewing >> >> >>>>>>>>> it. >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >> >> >>>>>>>>> works but >> >> >>>>>>>>> 3.x throws a segfault? >> >> >>>>>>>>> >> >> >>>>>>>>> Thanks in advance, >> >> >>>>>>>>> Cyd >> >> >>>>>>>>> ________________________________ >> >> >>>>>>>>> >> >> >>>>>>>>> Python-Dev mailing list >> >> >>>>>>>>> >> >> >>>>>>>>> Python-Dev at python.org >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>>>>> Unsubscribe: >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> >> >> >>>>>>>> -- >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> -- >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >>>>>> >> >> >>>>>> ________________________________ >> >> >>>>>> >> >> >>>>>> Python-Dev mailing list >> >> >>>>>> Python-Dev at python.org >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >>>>>> Unsubscribe: >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> -- >> >> >>>>> Ryan >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will be >> >> >>>>> simple: >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >>>>> that was >> >> >>>>> nul-terminated." >> >> >>>>> Personal reality distortion fields are immune to contradictory >> >> >>>>> evidence. >> >> >>>>> - >> >> >>>>> srean >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >>> >> >> >>> >> >> >>> -- >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> > >> > >> > >> > >> > -- >> > Ryan >> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >> > nul-terminated." >> > Personal reality distortion fields are immune to contradictory evidence. >> > - >> > srean >> > Check out my website: http://kirbyfan64.github.io/ > > > > > -- > 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/ From chaselton at gmail.com Fri Jan 30 21:49:30 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 14:49:30 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: I've got a page of all of the modifications to source files I've used in my attempts to get 3.4.2 working...I can post it somewhere if the port ever succeeds. On Fri, Jan 30, 2015 at 2:07 PM, Victor Stinner wrote: > Oh, I found my old patch to force UTF-8 on Android. I didn't test it: > see attached file. > > It would be nice to start a wiki page to collect all informations on > the Python port to Android. > > Victor > > 2015-01-30 21:04 GMT+01:00 Victor Stinner : >> Android provides a minimal support of locales. Most functions return a >> fake result, do nothing. I'm not sure that it supports any codec. To >> support Android, we may force UTF-8 for the filesystem encoding, as >> done on Mac OS X. >> >> Victor >> >> 2015-01-30 19:04 GMT+01:00 Ryan Gonzalez : >>> No... >>> >>> ...but I think I found the issue with grep. Try applying the attached patch >>> to the Python/frozenmain.c. It comments out the locale handling. >>> >>> It seems that Python always calls its strdup function on the locale string. >>> On Android, this can apparently be null (as seen in the bug report you >>> linked to). >>> >>> On Fri, Jan 30, 2015 at 12:00 PM, Cyd Haselton wrote: >>>> >>>> I don't have gdb on device; does the following tell you where Python's >>>> strdup is called? >>>> >>>> >> _PyMem_RawStrdup >>>> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >>>> >>>> On Fri, Jan 30, 2015 at 11:52 AM, Ryan Gonzalez wrote: >>>> > Is it possible at all to get a stack trace of the crash using gdb? Try >>>> > the >>>> > steps here. >>>> > >>>> > That way we can see where Python's own strdup function is getting >>>> > called. >>>> > >>>> > On Fri, Jan 30, 2015 at 9:05 AM, Cyd Haselton >>>> > 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 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 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 >>>> >> >> wrote: >>>> >> >>> >>>> >> >>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >>>> >> >>> >>>> >> >>> wrote: >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> What I see in the strace: >>>> >> >>>> >>>> >> >>>> ... load libpython3.4m.so.1.0 >>>> >> >>>> ... load libm >>>> >> >>>> ... open /dev/__properties__ and do something to it >>>> >> >>>> (what?) >>>> >> >>>> ... get current time >>>> >> >>>> ... allocate memory >>>> >> >>>> ... getuid >>>> >> >>>> ... segfault >>>> >> >>>> >>>> >> >>>> That's not a lot to go on, but it doesn't look as if it has >>>> >> >>>> started >>>> >> >>>> to >>>> >> >>>> load modules yet. >>>> >> >>>> >>>> >> >>>> Does /dev/__properties__ ring a bell? Not to me. >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>>> >> >>> is the code that works with that file. >>>> >> >>> >>>> >> >>> This explains it a bit (slides 24-29). Looks like something to do >>>> >> >>> with >>>> >> >>> interprocess communication. Likely has nothing to do with Python >>>> >> >>> itself. >>>> >> >>> >>>> >> >>> Maybe this would be useful? >>>> >> >>> >>>> >> >>>> >>>> >> >>>> That stack trace would be really helpful. >>>> >> >>>> >>>> >> >>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>>> >> >>>> >>>> >> >>>> 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 >>>> >> >>>>> >>>> >> >>>>> 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 >>>> >> >>>>>> >>>> >> >>>>>> wrote: >>>> >> >>>>>>> >>>> >> >>>>>>> >>>> >> >>>>>>> All, >>>> >> >>>>>>> I recently ditched my attempts to port Python 2.7.8 to Android >>>> >> >>>>>>> in >>>> >> >>>>>>> favor of Python 3.4.2. Unfortunately, after using the same >>>> >> >>>>>>> configure >>>> >> >>>>>>> options in the same environment, and modifying the setup.py as >>>> >> >>>>>>> needed, >>>> >> >>>>>>> the newly built binary throws a segfault when the >>>> >> >>>>>>> generate-posix-vars >>>> >> >>>>>>> portion of the build is reached...and when it is run as well >>>> >> >>>>>>> (i.e. >>>> >> >>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) >>>> >> >>>>>>> >>>> >> >>>>>>> I took a strace of ./python, however I'm a bit lost when >>>> >> >>>>>>> reviewing >>>> >> >>>>>>> it. >>>> >> >>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 >>>> >> >>>>>>> works >>>> >> >>>>>>> but >>>> >> >>>>>>> 3.x throws a segfault? >>>> >> >>>>>>> >>>> >> >>>>>>> Thanks in advance, >>>> >> >>>>>>> Cyd >>>> >> >>>>>>> ________________________________ >>>> >> >>>>>>> >>>> >> >>>>>>> Python-Dev mailing list >>>> >> >>>>>>> >>>> >> >>>>>>> Python-Dev at python.org >>>> >> >>>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>> >> >>>>>>> Unsubscribe: >>>> >> >>>>>>> >>>> >> >>>>>>> >>>> >> >>>>>>> >>>> >> >>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> >>>> >> >>>>>> -- >>>> >> >>>>>> --Guido van Rossum (python.org/~guido) >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> -- >>>> >> >>>> --Guido van Rossum (python.org/~guido) >>>> >> >>>> >>>> >> >>>> ________________________________ >>>> >> >>>> >>>> >> >>>> Python-Dev mailing list >>>> >> >>>> Python-Dev at python.org >>>> >> >>>> https://mail.python.org/mailman/listinfo/python-dev >>>> >> >>>> Unsubscribe: >>>> >> >>>> >>>> >> >>>> >>>> >> >>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> -- >>>> >> >>> Ryan >>>> >> >>> If anybody ever asks me why I prefer C++ to C, my answer will be >>>> >> >>> simple: >>>> >> >>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >>>> >> >>> that >>>> >> >>> was >>>> >> >>> nul-terminated." >>>> >> >>> Personal reality distortion fields are immune to contradictory >>>> >> >>> evidence. >>>> >> >>> - >>>> >> >>> srean >>>> >> >>> Check out my website: http://kirbyfan64.github.io/ >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>>> >> > Check out my website: http://kirbyfan64.github.io/ >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Ryan >>>> > If anybody ever asks me why I prefer C++ to C, my answer will be simple: >>>> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was >>>> > nul-terminated." >>>> > Personal reality distortion fields are immune to contradictory evidence. >>>> > - >>>> > srean >>>> > Check out my website: http://kirbyfan64.github.io/ >>> >>> >>> >>> >>> -- >>> 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/ >>> >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev at python.org >>> https://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com >>> From chaselton at gmail.com Fri Jan 30 21:50:39 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 14:50:39 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 >> > 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 >> >> 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 >> >> >> 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 >> >> >> > >> >> >> > 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 >> >> >> >> >> >> >> >> 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 >> >> >> >> > >> >> >> >> > 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 >> >> >> >> >> 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 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 >> >> >> >> >>>> >> >> >> >> >>>> wrote: >> >> >> >> >>>>> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >> >> >>>>> >> >> >> >> >>>>> wrote: >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> What I see in the strace: >> >> >> >> >>>>>> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >> >> >>>>>> ... load libm >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >> >> >>>>>> (what?) >> >> >> >> >>>>>> ... get current time >> >> >> >> >>>>>> ... allocate memory >> >> >> >> >>>>>> ... getuid >> >> >> >> >>>>>> ... segfault >> >> >> >> >>>>>> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if it >> >> >> >> >>>>>> has >> >> >> >> >>>>>> started to >> >> >> >> >>>>>> load modules yet. >> >> >> >> >>>>>> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >> >> >>>>> is the code that works with that file. >> >> >> >> >>>>> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like >> >> >> >> >>>>> something >> >> >> >> >>>>> to >> >> >> >> >>>>> do >> >> >> >> >>>>> with >> >> >> >> >>>>> interprocess communication. Likely has nothing to do with >> >> >> >> >>>>> Python >> >> >> >> >>>>> itself. >> >> >> >> >>>>> >> >> >> >> >>>>> Maybe this would be useful? >> >> >> >> >>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> That stack trace would be really helpful. >> >> >> >> >>>>>> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >> >> >>>>>> >> >> >> >> >>>>>> 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 >> >> >> >> >>>>>>> >> >> >> >> >>>>>>> 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 >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> wrote: >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> All, >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to >> >> >> >> >>>>>>>>> Android >> >> >> >> >>>>>>>>> in >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the >> >> >> >> >>>>>>>>> same >> >> >> >> >>>>>>>>> configure >> >> >> >> >>>>>>>>> options in the same environment, and modifying the >> >> >> >> >>>>>>>>> setup.py >> >> >> >> >>>>>>>>> as >> >> >> >> >>>>>>>>> needed, >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when the >> >> >> >> >>>>>>>>> generate-posix-vars >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is run >> >> >> >> >>>>>>>>> as >> >> >> >> >>>>>>>>> well >> >> >> >> >>>>>>>>> (i.e. >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or >> >> >> >> >>>>>>>>> similar) >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost >> >> >> >> >>>>>>>>> when >> >> >> >> >>>>>>>>> reviewing >> >> >> >> >>>>>>>>> it. >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python >> >> >> >> >>>>>>>>> 2.7 >> >> >> >> >>>>>>>>> works but >> >> >> >> >>>>>>>>> 3.x throws a segfault? >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> Thanks in advance, >> >> >> >> >>>>>>>>> Cyd >> >> >> >> >>>>>>>>> ________________________________ >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> Python-Dev mailing list >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> Python-Dev at python.org >> >> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >>>>>>>>> Unsubscribe: >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> >> >> >> >> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> >> >> >> >> >>>>>>>> -- >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> -- >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >>>>>> >> >> >> >> >>>>>> ________________________________ >> >> >> >> >>>>>> >> >> >> >> >>>>>> Python-Dev mailing list >> >> >> >> >>>>>> Python-Dev at python.org >> >> >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >>>>>> Unsubscribe: >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> >> >> >> >> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> >> >> >> >> >>>>> -- >> >> >> >> >>>>> Ryan >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer >> >> >> >> >>>>> will >> >> >> >> >>>>> be >> >> >> >> >>>>> simple: >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't >> >> >> >> >>>>> think >> >> >> >> >>>>> that was >> >> >> >> >>>>> nul-terminated." >> >> >> >> >>>>> Personal reality distortion fields are immune to >> >> >> >> >>>>> contradictory >> >> >> >> >>>>> evidence. >> >> >> >> >>>>> - >> >> >> >> >>>>> srean >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my >> >> >> >> >>> brevity. >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Ryan >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer will be >> >> >> > simple: >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >> > that >> >> >> > was >> >> >> > nul-terminated." >> >> >> > Personal reality distortion fields are immune to contradictory >> >> >> > evidence. >> >> >> > - >> >> >> > srean >> >> >> > Check out my website: http://kirbyfan64.github.io/ >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > 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/ From rymg19 at gmail.com Fri Jan 30 20:00:05 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 13:00:05 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 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 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 > 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 > >> > 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 > >> >> 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 > > >> >> > 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 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 wrote: > >> >> >>>> > >> >> >>>> Managed to get this out of logcat: > >> >> >>>> F(11914) Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), > thread > >> >> >>>> 11914 (python) (libc) > >> >> >>>> > >> >> >>>> [ 01-29 19:30:55.855 23373:23373 F/libc ] > >> >> >>>> Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 23373 > >> >> >>>> (python) > >> >> >>>> > >> >> >>>> Less detail than strace but it seems to be that python is > >> >> >>>> segfaulting > >> >> >>>> libc... > >> >> >>>> > >> >> >>>> On Wed, Jan 28, 2015 at 11:23 AM, Ryan Gonzalez < > rymg19 at gmail.com> > >> >> >>>> wrote: > >> >> >>>>> > >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum > >> >> >>>>> > >> >> >>>>> wrote: > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> What I see in the strace: > >> >> >>>>>> > >> >> >>>>>> ... load libpython3.4m.so.1.0 > >> >> >>>>>> ... load libm > >> >> >>>>>> ... open /dev/__properties__ and do something to it > >> >> >>>>>> (what?) > >> >> >>>>>> ... get current time > >> >> >>>>>> ... allocate memory > >> >> >>>>>> ... getuid > >> >> >>>>>> ... segfault > >> >> >>>>>> > >> >> >>>>>> That's not a lot to go on, but it doesn't look as if it has > >> >> >>>>>> started to > >> >> >>>>>> load modules yet. > >> >> >>>>>> > >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >> >> >>>>> is the code that works with that file. > >> >> >>>>> > >> >> >>>>> This explains it a bit (slides 24-29). Looks like something to > >> >> >>>>> do > >> >> >>>>> with > >> >> >>>>> interprocess communication. Likely has nothing to do with > Python > >> >> >>>>> itself. > >> >> >>>>> > >> >> >>>>> Maybe this would be useful? > >> >> >>>>> > >> >> >>>>>> > >> >> >>>>>> That stack trace would be really helpful. > >> >> >>>>>> > >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > >> >> >>>>>> > >> >> >>>>>> 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 > >> >> >>>>>>> > >> >> >>>>>>> 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 > >> >> >>>>>>>> > >> >> >>>>>>>> wrote: > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> All, > >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 to > >> >> >>>>>>>>> Android > >> >> >>>>>>>>> in > >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using the > same > >> >> >>>>>>>>> configure > >> >> >>>>>>>>> options in the same environment, and modifying the > setup.py > >> >> >>>>>>>>> as > >> >> >>>>>>>>> needed, > >> >> >>>>>>>>> the newly built binary throws a segfault when the > >> >> >>>>>>>>> generate-posix-vars > >> >> >>>>>>>>> portion of the build is reached...and when it is run as > well > >> >> >>>>>>>>> (i.e. > >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or similar) > >> >> >>>>>>>>> > >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost when > >> >> >>>>>>>>> reviewing > >> >> >>>>>>>>> it. > >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why Python 2.7 > >> >> >>>>>>>>> works but > >> >> >>>>>>>>> 3.x throws a segfault? > >> >> >>>>>>>>> > >> >> >>>>>>>>> Thanks in advance, > >> >> >>>>>>>>> Cyd > >> >> >>>>>>>>> ________________________________ > >> >> >>>>>>>>> > >> >> >>>>>>>>> Python-Dev mailing list > >> >> >>>>>>>>> > >> >> >>>>>>>>> Python-Dev at python.org > >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >> >>>>>>>>> Unsubscribe: > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> > >> >> >>>>>>>> -- > >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> -- > >> >> >>>>>> --Guido van Rossum (python.org/~guido) > >> >> >>>>>> > >> >> >>>>>> ________________________________ > >> >> >>>>>> > >> >> >>>>>> Python-Dev mailing list > >> >> >>>>>> Python-Dev at python.org > >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >> >>>>>> Unsubscribe: > >> >> >>>>>> > >> >> >>>>>> > >> >> >>>>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> > >> >> >>>>> -- > >> >> >>>>> Ryan > >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer will > be > >> >> >>>>> simple: > >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't > think > >> >> >>>>> that was > >> >> >>>>> nul-terminated." > >> >> >>>>> Personal reality distortion fields are immune to contradictory > >> >> >>>>> evidence. > >> >> >>>>> - > >> >> >>>>> srean > >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my > brevity. > >> >> >>> Check out my website: http://kirbyfan64.github.io/ > >> > > >> > > >> > > >> > > >> > -- > >> > Ryan > >> > If anybody ever asks me why I prefer C++ to C, my answer will be > simple: > >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that > was > >> > nul-terminated." > >> > Personal reality distortion fields are immune to contradictory > evidence. > >> > - > >> > srean > >> > Check out my website: http://kirbyfan64.github.io/ > > > > > > > > > > -- > > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Fri Jan 30 23:19:02 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 16:19:02 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 > >> > 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 > >> >> 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 at 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 > > >> >> >> 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 > >> >> >> > > >> >> >> > 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 > >> >> >> >> > >> >> >> >> 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 > >> >> >> >> > > >> >> >> >> > 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 > >> >> >> >> >> 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 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 > >> >> >> >> >>>> > >> >> >> >> >>>> wrote: > >> >> >> >> >>>>> > >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum > >> >> >> >> >>>>> > >> >> >> >> >>>>> wrote: > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> What I see in the strace: > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 > >> >> >> >> >>>>>> ... load libm > >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it > >> >> >> >> >>>>>> (what?) > >> >> >> >> >>>>>> ... get current time > >> >> >> >> >>>>>> ... allocate memory > >> >> >> >> >>>>>> ... getuid > >> >> >> >> >>>>>> ... segfault > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if it > >> >> >> >> >>>>>> has > >> >> >> >> >>>>>> started to > >> >> >> >> >>>>>> load modules yet. > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >> >> >> >> >>>>> is the code that works with that file. > >> >> >> >> >>>>> > >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like > >> >> >> >> >>>>> something > >> >> >> >> >>>>> to > >> >> >> >> >>>>> do > >> >> >> >> >>>>> with > >> >> >> >> >>>>> interprocess communication. Likely has nothing to do > with > >> >> >> >> >>>>> Python > >> >> >> >> >>>>> itself. > >> >> >> >> >>>>> > >> >> >> >> >>>>> Maybe this would be useful? > >> >> >> >> >>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> That stack trace would be really helpful. > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> 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 > >> >> >> >> >>>>>>> > >> >> >> >> >>>>>>> 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 > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> wrote: > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> All, > >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 > to > >> >> >> >> >>>>>>>>> Android > >> >> >> >> >>>>>>>>> in > >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using > the > >> >> >> >> >>>>>>>>> same > >> >> >> >> >>>>>>>>> configure > >> >> >> >> >>>>>>>>> options in the same environment, and modifying the > >> >> >> >> >>>>>>>>> setup.py > >> >> >> >> >>>>>>>>> as > >> >> >> >> >>>>>>>>> needed, > >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when the > >> >> >> >> >>>>>>>>> generate-posix-vars > >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is run > >> >> >> >> >>>>>>>>> as > >> >> >> >> >>>>>>>>> well > >> >> >> >> >>>>>>>>> (i.e. > >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or > >> >> >> >> >>>>>>>>> similar) > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost > >> >> >> >> >>>>>>>>> when > >> >> >> >> >>>>>>>>> reviewing > >> >> >> >> >>>>>>>>> it. > >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why > Python > >> >> >> >> >>>>>>>>> 2.7 > >> >> >> >> >>>>>>>>> works but > >> >> >> >> >>>>>>>>> 3.x throws a segfault? > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> Thanks in advance, > >> >> >> >> >>>>>>>>> Cyd > >> >> >> >> >>>>>>>>> ________________________________ > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> Python-Dev mailing list > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> Python-Dev at python.org > >> >> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >> >> >> >>>>>>>>> Unsubscribe: > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > >> >> >> >> >>>>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> > >> >> >> >> >>>>>>>> -- > >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> -- > >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> ________________________________ > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> Python-Dev mailing list > >> >> >> >> >>>>>> Python-Dev at python.org > >> >> >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >> >> >> >>>>>> Unsubscribe: > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > >> >> >> >> >>>>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> > >> >> >> >> >>>>> -- > >> >> >> >> >>>>> Ryan > >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my answer > >> >> >> >> >>>>> will > >> >> >> >> >>>>> be > >> >> >> >> >>>>> simple: > >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I > don't > >> >> >> >> >>>>> think > >> >> >> >> >>>>> that was > >> >> >> >> >>>>> nul-terminated." > >> >> >> >> >>>>> Personal reality distortion fields are immune to > >> >> >> >> >>>>> contradictory > >> >> >> >> >>>>> evidence. > >> >> >> >> >>>>> - > >> >> >> >> >>>>> srean > >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ > >> >> >> >> >>> > >> >> >> >> >>> > >> >> >> >> >>> -- > >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my > >> >> >> >> >>> brevity. > >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > Ryan > >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer will be > >> >> >> > simple: > >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think > >> >> >> > that > >> >> >> > was > >> >> >> > nul-terminated." > >> >> >> > Personal reality distortion fields are immune to contradictory > >> >> >> > evidence. > >> >> >> > - > >> >> >> > srean > >> >> >> > Check out my website: http://kirbyfan64.github.io/ > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at krypto.org Sat Jan 31 00:26:08 2015 From: greg at krypto.org (Gregory P. Smith) Date: Fri, 30 Jan 2015 23:26:08 +0000 Subject: [Python-Dev] Can Python Be Built Without Distutils References: <54C29784.2080908@ubuntu.com> <54C29ED2.2050508@egenix.com> <54C40632.4020301@egenix.com> <20150124232430.49c859ca@fsol> <20150125160753.53b98d7b@fsol> Message-ID: On Sun Jan 25 2015 at 7:08:53 AM Antoine Pitrou wrote: > On Sun, 25 Jan 2015 05:22:48 +0000 > "Gregory P. Smith" wrote: > > Why doesn't our Makefile supply that flag with the make parallelism level > > in the sharedmods step? > > If I run "make -j4" here, it works (on the default branch). > Thanks, glad to see that this was added! :) This looks like a feature that was added in 3.5. Rather than passing the flag to setup.py from the Makefile (where I had been looking for it), setup.py looks at the MAKEFLAGS environment variable and turns on distutils.common.build_ext's parallel flag if "-j" is found in that. By default it will then do a parallel build using os.cpu_count() number of tasks. -gps > > Regards > > Antoine. > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > greg%40krypto.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Sat Jan 31 01:19:56 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Fri, 30 Jan 2015 18:19:56 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 >> >> > 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 >> >> >> 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 >> >> >> >> >> >> >> >> 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 >> >> >> >> > >> >> >> >> > 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 >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> > >> >> >> >> >> > 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 >> >> >> >> >> >> 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 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 >> >> >> >> >> >>>> >> >> >> >> >> >>>> wrote: >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> wrote: >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> What I see in the strace: >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >> >> >> >>>>>> ... load libm >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >> >> >> >>>>>> (what?) >> >> >> >> >> >>>>>> ... get current time >> >> >> >> >> >>>>>> ... allocate memory >> >> >> >> >> >>>>>> ... getuid >> >> >> >> >> >>>>>> ... segfault >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if >> >> >> >> >> >>>>>> it >> >> >> >> >> >>>>>> has >> >> >> >> >> >>>>>> started to >> >> >> >> >> >>>>>> load modules yet. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >> >> >> >>>>> is the code that works with that file. >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like >> >> >> >> >> >>>>> something >> >> >> >> >> >>>>> to >> >> >> >> >> >>>>> do >> >> >> >> >> >>>>> with >> >> >> >> >> >>>>> interprocess communication. Likely has nothing to do >> >> >> >> >> >>>>> with >> >> >> >> >> >>>>> Python >> >> >> >> >> >>>>> itself. >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> Maybe this would be useful? >> >> >> >> >> >>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> That stack trace would be really helpful. >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> 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 >> >> >> >> >> >>>>>>> >> >> >> >> >> >>>>>>> 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 >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> wrote: >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> All, >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python 2.7.8 >> >> >> >> >> >>>>>>>>> to >> >> >> >> >> >>>>>>>>> Android >> >> >> >> >> >>>>>>>>> in >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after using >> >> >> >> >> >>>>>>>>> the >> >> >> >> >> >>>>>>>>> same >> >> >> >> >> >>>>>>>>> configure >> >> >> >> >> >>>>>>>>> options in the same environment, and modifying the >> >> >> >> >> >>>>>>>>> setup.py >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >>>>>>>>> needed, >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when the >> >> >> >> >> >>>>>>>>> generate-posix-vars >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is >> >> >> >> >> >>>>>>>>> run >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >>>>>>>>> well >> >> >> >> >> >>>>>>>>> (i.e. >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or >> >> >> >> >> >>>>>>>>> similar) >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit lost >> >> >> >> >> >>>>>>>>> when >> >> >> >> >> >>>>>>>>> reviewing >> >> >> >> >> >>>>>>>>> it. >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why >> >> >> >> >> >>>>>>>>> Python >> >> >> >> >> >>>>>>>>> 2.7 >> >> >> >> >> >>>>>>>>> works but >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> Thanks in advance, >> >> >> >> >> >>>>>>>>> Cyd >> >> >> >> >> >>>>>>>>> ________________________________ >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> Python-Dev mailing list >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> Python-Dev at python.org >> >> >> >> >> >>>>>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >>>>>>>>> Unsubscribe: >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >>>>>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >>>>>>>> -- >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> -- >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> ________________________________ >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> Python-Dev mailing list >> >> >> >> >> >>>>>> Python-Dev at python.org >> >> >> >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >>>>>> Unsubscribe: >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> >>>>> -- >> >> >> >> >> >>>>> Ryan >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my >> >> >> >> >> >>>>> answer >> >> >> >> >> >>>>> will >> >> >> >> >> >>>>> be >> >> >> >> >> >>>>> simple: >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I >> >> >> >> >> >>>>> don't >> >> >> >> >> >>>>> think >> >> >> >> >> >>>>> that was >> >> >> >> >> >>>>> nul-terminated." >> >> >> >> >> >>>>> Personal reality distortion fields are immune to >> >> >> >> >> >>>>> contradictory >> >> >> >> >> >>>>> evidence. >> >> >> >> >> >>>>> - >> >> >> >> >> >>>>> srean >> >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> -- >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse my >> >> >> >> >> >>> brevity. >> >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Ryan >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer will >> >> >> >> > be >> >> >> >> > simple: >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think >> >> >> >> > that >> >> >> >> > was >> >> >> >> > nul-terminated." >> >> >> >> > Personal reality distortion fields are immune to contradictory >> >> >> >> > evidence. >> >> >> >> > - >> >> >> >> > srean >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > 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/ From rymg19 at gmail.com Sat Jan 31 02:51:12 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 19:51:12 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 < > chaselton at 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 > > >> >> >> 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 > >> >> >> >> > >> >> >> >> 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 > >> >> >> >> > > >> >> >> >> > 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 > >> >> >> >> >> > >> >> >> >> >> 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 > >> >> >> >> >> > > >> >> >> >> >> > 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 > >> >> >> >> >> >> 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 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 > >> >> >> >> >> >>>> > >> >> >> >> >> >>>> wrote: > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> wrote: > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> What I see in the strace: > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 > >> >> >> >> >> >>>>>> ... load libm > >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it > >> >> >> >> >> >>>>>> (what?) > >> >> >> >> >> >>>>>> ... get current time > >> >> >> >> >> >>>>>> ... allocate memory > >> >> >> >> >> >>>>>> ... getuid > >> >> >> >> >> >>>>>> ... segfault > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as if > >> >> >> >> >> >>>>>> it > >> >> >> >> >> >>>>>> has > >> >> >> >> >> >>>>>> started to > >> >> >> >> >> >>>>>> load modules yet. > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >> >> >> >> >> >>>>> is the code that works with that file. > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like > >> >> >> >> >> >>>>> something > >> >> >> >> >> >>>>> to > >> >> >> >> >> >>>>> do > >> >> >> >> >> >>>>> with > >> >> >> >> >> >>>>> interprocess communication. Likely has nothing to do > >> >> >> >> >> >>>>> with > >> >> >> >> >> >>>>> Python > >> >> >> >> >> >>>>> itself. > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> Maybe this would be useful? > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> That stack trace would be really helpful. > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> 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 > >> >> >> >> >> >>>>>>> > >> >> >> >> >> >>>>>>> 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 > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> wrote: > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> All, > >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python > 2.7.8 > >> >> >> >> >> >>>>>>>>> to > >> >> >> >> >> >>>>>>>>> Android > >> >> >> >> >> >>>>>>>>> in > >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after > using > >> >> >> >> >> >>>>>>>>> the > >> >> >> >> >> >>>>>>>>> same > >> >> >> >> >> >>>>>>>>> configure > >> >> >> >> >> >>>>>>>>> options in the same environment, and modifying > the > >> >> >> >> >> >>>>>>>>> setup.py > >> >> >> >> >> >>>>>>>>> as > >> >> >> >> >> >>>>>>>>> needed, > >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when the > >> >> >> >> >> >>>>>>>>> generate-posix-vars > >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is > >> >> >> >> >> >>>>>>>>> run > >> >> >> >> >> >>>>>>>>> as > >> >> >> >> >> >>>>>>>>> well > >> >> >> >> >> >>>>>>>>> (i.e. > >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or > >> >> >> >> >> >>>>>>>>> similar) > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit > lost > >> >> >> >> >> >>>>>>>>> when > >> >> >> >> >> >>>>>>>>> reviewing > >> >> >> >> >> >>>>>>>>> it. > >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why > >> >> >> >> >> >>>>>>>>> Python > >> >> >> >> >> >>>>>>>>> 2.7 > >> >> >> >> >> >>>>>>>>> works but > >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> Thanks in advance, > >> >> >> >> >> >>>>>>>>> Cyd > >> >> >> >> >> >>>>>>>>> ________________________________ > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> Python-Dev mailing list > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> Python-Dev at python.org > >> >> >> >> >> >>>>>>>>> > https://mail.python.org/mailman/listinfo/python-dev > >> >> >> >> >> >>>>>>>>> Unsubscribe: > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > >> >> >> >> >> >>>>>>>>> > https://mail.python.org/mailman/options/python-dev/guido%40python.org > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> > >> >> >> >> >> >>>>>>>> -- > >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> -- > >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> ________________________________ > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> Python-Dev mailing list > >> >> >> >> >> >>>>>> Python-Dev at python.org > >> >> >> >> >> >>>>>> https://mail.python.org/mailman/listinfo/python-dev > >> >> >> >> >> >>>>>> Unsubscribe: > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > >> >> >> >> >> >>>>>> > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> > >> >> >> >> >> >>>>> -- > >> >> >> >> >> >>>>> Ryan > >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my > >> >> >> >> >> >>>>> answer > >> >> >> >> >> >>>>> will > >> >> >> >> >> >>>>> be > >> >> >> >> >> >>>>> simple: > >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I > >> >> >> >> >> >>>>> don't > >> >> >> >> >> >>>>> think > >> >> >> >> >> >>>>> that was > >> >> >> >> >> >>>>> nul-terminated." > >> >> >> >> >> >>>>> Personal reality distortion fields are immune to > >> >> >> >> >> >>>>> contradictory > >> >> >> >> >> >>>>> evidence. > >> >> >> >> >> >>>>> - > >> >> >> >> >> >>>>> srean > >> >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ > >> >> >> >> >> >>> > >> >> >> >> >> >>> > >> >> >> >> >> >>> -- > >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please excuse > my > >> >> >> >> >> >>> brevity. > >> >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > Ryan > >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer will > >> >> >> >> > be > >> >> >> >> > simple: > >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't > think > >> >> >> >> > that > >> >> >> >> > was > >> >> >> >> > nul-terminated." > >> >> >> >> > Personal reality distortion fields are immune to > contradictory > >> >> >> >> > evidence. > >> >> >> >> > - > >> >> >> >> > srean > >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From +18562547597 at tmomail.net Thu Jan 29 05:42:04 2015 From: +18562547597 at tmomail.net (+18562547597 at tmomail.net) Date: Thu, 29 Jan 2015 04:42:04 GMT Subject: [Python-Dev] (no subject) Message-ID: 20150029044210443174@mavenir.com An HTML attachment was scrubbed... URL: -------------- next part -------------- Who's this a symbol was sent to my man's phone I clicked the symbol and then it was at MESSAGE options -------------- next part -------------- A non-text attachment was scrubbed... Name: tmobilespace.gif Type: image/gif Size: 799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dottedline600.gif Type: image/gif Size: 872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: footer.gif Type: image/gif Size: 3589 bytes Desc: not available URL: From tetsuya.morimoto at gmail.com Sat Jan 31 05:56:17 2015 From: tetsuya.morimoto at gmail.com (Tetsuya Morimoto) Date: Sat, 31 Jan 2015 13:56:17 +0900 Subject: [Python-Dev] Results of the python 2.x and 3.x use survey, 2014 edition In-Reply-To: References: Message-ID: Thank you for your hard work. That's very helpful! thanks, Tetsuya On Fri, Jan 30, 2015 at 2:49 AM, Bruno Cauet wrote: > Hi! > Finally, here are the results: > http://blog.frite-camembert.net/python-survey-2014.html > Here is the auto-generated Google Forms recap: > > https://docs.google.com/forms/d/1DqxkNi4GvyTCu54usSdE1DjW29zw1tc52iMeH3z4heg/viewanalytics > (more elegant than my matplotlib graphs - I'd have no future as a > designer). > > Overall people started writing more python 3: +15 points in "I ever > wrote python 3 code", +10 points in "I write more python 3 than 2". > Transition is still ongoing and I hope a tipping point will be soon be > attained. > Users definitely seem to want to switch to python 3, but dependencies > keep them with 2.7 (I weep for the few ones still on 2.5). > > I also posted the results on HN > (https://news.ycombinator.com/item?id=8967645) and reddit > ( > http://www.reddit.com/r/Python/comments/2u3oh0/results_of_the_python_2x_and_3x_use_survey_2014/ > ). > Have a nice day, and a year full of python 3! > > Bruno Cauet > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/tetsuya.morimoto%40gmail.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sat Jan 31 02:52:47 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Fri, 30 Jan 2015 19:52:47 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: 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 < >> chaselton at 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 at 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 >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> > >> >> >> >> >> > 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 >> >> >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> >> > >> >> >> >> >> >> > 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 > > >> >> >> >> >> >> >> 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 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 >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> wrote: >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> wrote: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> What I see in the strace: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >> >> >> >> >>>>>> ... load libm >> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >> >> >> >> >>>>>> (what?) >> >> >> >> >> >> >>>>>> ... get current time >> >> >> >> >> >> >>>>>> ... allocate memory >> >> >> >> >> >> >>>>>> ... getuid >> >> >> >> >> >> >>>>>> ... segfault >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as >> if >> >> >> >> >> >> >>>>>> it >> >> >> >> >> >> >>>>>> has >> >> >> >> >> >> >>>>>> started to >> >> >> >> >> >> >>>>>> load modules yet. >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >> >> >> >> >>>>> is the code that works with that file. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like >> >> >> >> >> >> >>>>> something >> >> >> >> >> >> >>>>> to >> >> >> >> >> >> >>>>> do >> >> >> >> >> >> >>>>> with >> >> >> >> >> >> >>>>> interprocess communication. Likely has nothing to do >> >> >> >> >> >> >>>>> with >> >> >> >> >> >> >>>>> Python >> >> >> >> >> >> >>>>> itself. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> Maybe this would be useful? >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> That stack trace would be really helpful. >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> 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 >> >> >> >> >> >> >>>>>>> >> >> >> >> >> >> >>>>>>> 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 >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> wrote: >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> All, >> >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python >> 2.7.8 >> >> >> >> >> >> >>>>>>>>> to >> >> >> >> >> >> >>>>>>>>> Android >> >> >> >> >> >> >>>>>>>>> in >> >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after >> using >> >> >> >> >> >> >>>>>>>>> the >> >> >> >> >> >> >>>>>>>>> same >> >> >> >> >> >> >>>>>>>>> configure >> >> >> >> >> >> >>>>>>>>> options in the same environment, and modifying >> the >> >> >> >> >> >> >>>>>>>>> setup.py >> >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >> >>>>>>>>> needed, >> >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when >> the >> >> >> >> >> >> >>>>>>>>> generate-posix-vars >> >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is >> >> >> >> >> >> >>>>>>>>> run >> >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >> >>>>>>>>> well >> >> >> >> >> >> >>>>>>>>> (i.e. >> >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or >> >> >> >> >> >> >>>>>>>>> similar) >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit >> lost >> >> >> >> >> >> >>>>>>>>> when >> >> >> >> >> >> >>>>>>>>> reviewing >> >> >> >> >> >> >>>>>>>>> it. >> >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why >> >> >> >> >> >> >>>>>>>>> Python >> >> >> >> >> >> >>>>>>>>> 2.7 >> >> >> >> >> >> >>>>>>>>> works but >> >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Thanks in advance, >> >> >> >> >> >> >>>>>>>>> Cyd >> >> >> >> >> >> >>>>>>>>> ________________________________ >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Python-Dev mailing list >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Python-Dev at python.org >> >> >> >> >> >> >>>>>>>>> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >> >>>>>>>>> Unsubscribe: >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> -- >> >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> -- >> >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> ________________________________ >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> Python-Dev mailing list >> >> >> >> >> >> >>>>>> Python-Dev at python.org >> >> >> >> >> >> >>>>>> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >> >>>>>> Unsubscribe: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> -- >> >> >> >> >> >> >>>>> Ryan >> >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my >> >> >> >> >> >> >>>>> answer >> >> >> >> >> >> >>>>> will >> >> >> >> >> >> >>>>> be >> >> >> >> >> >> >>>>> simple: >> >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I >> >> >> >> >> >> >>>>> don't >> >> >> >> >> >> >>>>> think >> >> >> >> >> >> >>>>> that was >> >> >> >> >> >> >>>>> nul-terminated." >> >> >> >> >> >> >>>>> Personal reality distortion fields are immune to >> >> >> >> >> >> >>>>> contradictory >> >> >> >> >> >> >>>>> evidence. >> >> >> >> >> >> >>>>> - >> >> >> >> >> >> >>>>> srean >> >> >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> -- >> >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please >> excuse my >> >> >> >> >> >> >>> brevity. >> >> >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Ryan >> >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer >> will >> >> >> >> >> > be >> >> >> >> >> > simple: >> >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't >> think >> >> >> >> >> > that >> >> >> >> >> > was >> >> >> >> >> > nul-terminated." >> >> >> >> >> > Personal reality distortion fields are immune to >> contradictory >> >> >> >> >> > evidence. >> >> >> >> >> > - >> >> >> >> >> > srean >> >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Sat Jan 31 13:10:51 2015 From: chaselton at gmail.com (chaselton at gmail.com) Date: Sat, 31 Jan 2015 06:10:51 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <543e1054-a437-4ed4-9c1d-3298e8ad0223@email.android.com> Message-ID: <7545e812-1a79-4389-8add-c0d6acdf03b3.maildroid@localhost> 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 < >> chaselton at 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 at 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 >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> > >> >> >> >> >> > 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 >> >> >> >> >> >> >> >> >> >> >> >> 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 >> >> >> >> >> >> > >> >> >> >> >> >> > 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 > > >> >> >> >> >> >> >> 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 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 >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> wrote: >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van Rossum >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> wrote: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> What I see in the strace: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >> >> >> >> >> >> >>>>>> ... load libm >> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something to it >> >> >> >> >> >> >>>>>> (what?) >> >> >> >> >> >> >>>>>> ... get current time >> >> >> >> >> >> >>>>>> ... allocate memory >> >> >> >> >> >> >>>>>> ... getuid >> >> >> >> >> >> >>>>>> ... segfault >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look as >> if >> >> >> >> >> >> >>>>>> it >> >> >> >> >> >> >>>>>> has >> >> >> >> >> >> >>>>>> started to >> >> >> >> >> >> >>>>>> load modules yet. >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to me. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >> >> >> >> >> >> >>>>> is the code that works with that file. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks like >> >> >> >> >> >> >>>>> something >> >> >> >> >> >> >>>>> to >> >> >> >> >> >> >>>>> do >> >> >> >> >> >> >>>>> with >> >> >> >> >> >> >>>>> interprocess communication. Likely has nothing to do >> >> >> >> >> >> >>>>> with >> >> >> >> >> >> >>>>> Python >> >> >> >> >> >> >>>>> itself. >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> Maybe this would be useful? >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> That stack trace would be really helpful. >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> 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 >> >> >> >> >> >> >>>>>>> >> >> >> >> >> >> >>>>>>> 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 >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> wrote: >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> All, >> >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port Python >> 2.7.8 >> >> >> >> >> >> >>>>>>>>> to >> >> >> >> >> >> >>>>>>>>> Android >> >> >> >> >> >> >>>>>>>>> in >> >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, after >> using >> >> >> >> >> >> >>>>>>>>> the >> >> >> >> >> >> >>>>>>>>> same >> >> >> >> >> >> >>>>>>>>> configure >> >> >> >> >> >> >>>>>>>>> options in the same environment, and modifying >> the >> >> >> >> >> >> >>>>>>>>> setup.py >> >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >> >>>>>>>>> needed, >> >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault when >> the >> >> >> >> >> >> >>>>>>>>> generate-posix-vars >> >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when it is >> >> >> >> >> >> >>>>>>>>> run >> >> >> >> >> >> >>>>>>>>> as >> >> >> >> >> >> >>>>>>>>> well >> >> >> >> >> >> >>>>>>>>> (i.e. >> >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m sysconfig, or >> >> >> >> >> >> >>>>>>>>> similar) >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a bit >> lost >> >> >> >> >> >> >>>>>>>>> when >> >> >> >> >> >> >>>>>>>>> reviewing >> >> >> >> >> >> >>>>>>>>> it. >> >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. why >> >> >> >> >> >> >>>>>>>>> Python >> >> >> >> >> >> >>>>>>>>> 2.7 >> >> >> >> >> >> >>>>>>>>> works but >> >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Thanks in advance, >> >> >> >> >> >> >>>>>>>>> Cyd >> >> >> >> >> >> >>>>>>>>> ________________________________ >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Python-Dev mailing list >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> Python-Dev at python.org >> >> >> >> >> >> >>>>>>>>> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >> >>>>>>>>> Unsubscribe: >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> >> >> >> >> >> >>>>>>>>> >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> >> >> >> >> >> >> >>>>>>>> -- >> >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> -- >> >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> ________________________________ >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> Python-Dev mailing list >> >> >> >> >> >> >>>>>> Python-Dev at python.org >> >> >> >> >> >> >>>>>> >> https://mail.python.org/mailman/listinfo/python-dev >> >> >> >> >> >> >>>>>> Unsubscribe: >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> >> >> >> >> >> >> >>>>> -- >> >> >> >> >> >> >>>>> Ryan >> >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, my >> >> >> >> >> >> >>>>> answer >> >> >> >> >> >> >>>>> will >> >> >> >> >> >> >>>>> be >> >> >> >> >> >> >>>>> simple: >> >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I >> >> >> >> >> >> >>>>> don't >> >> >> >> >> >> >>>>> think >> >> >> >> >> >> >>>>> that was >> >> >> >> >> >> >>>>> nul-terminated." >> >> >> >> >> >> >>>>> Personal reality distortion fields are immune to >> >> >> >> >> >> >>>>> contradictory >> >> >> >> >> >> >>>>> evidence. >> >> >> >> >> >> >>>>> - >> >> >> >> >> >> >>>>> srean >> >> >> >> >> >> >>>>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> -- >> >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please >> excuse my >> >> >> >> >> >> >>> brevity. >> >> >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Ryan >> >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my answer >> will >> >> >> >> >> > be >> >> >> >> >> > simple: >> >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't >> think >> >> >> >> >> > that >> >> >> >> >> > was >> >> >> >> >> > nul-terminated." >> >> >> >> >> > Personal reality distortion fields are immune to >> contradictory >> >> >> >> >> > evidence. >> >> >> >> >> > - >> >> >> >> >> > srean >> >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > 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/ From chaselton at gmail.com Sat Jan 31 19:12:02 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sat, 31 Jan 2015 12:12:02 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: 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 < >>> chaselton at 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 at 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 >>> >> >> >> >> >>> >> >> >> >> 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 >>> >> >> >> >> > >>> >> >> >> >> > 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 >>> >> >> >> >> >> >>> >> >> >> >> >> 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 >>> >> >> >> >> >> > >>> >> >> >> >> >> > 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 > >> > >>> >> >> >> >> >> >> 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 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 >>> >> >> >> >> >> >>>> >>> >> >> >> >> >> >>>> wrote: >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >Rossum >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> wrote: >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> What I see in the strace: >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>> >> >> >> >> >> >>>>>> ... load libm >>> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something >to it >>> >> >> >> >> >> >>>>>> (what?) >>> >> >> >> >> >> >>>>>> ... get current time >>> >> >> >> >> >> >>>>>> ... allocate memory >>> >> >> >> >> >> >>>>>> ... getuid >>> >> >> >> >> >> >>>>>> ... segfault >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't >look as >>> if >>> >> >> >> >> >> >>>>>> it >>> >> >> >> >> >> >>>>>> has >>> >> >> >> >> >> >>>>>> started to >>> >> >> >> >> >> >>>>>> load modules yet. >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to >me. >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sat Jan 31 20:10:18 2015 From: rymg19 at gmail.com (Ryan) Date: Sat, 31 Jan 2015 13:10:18 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: Message-ID: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> 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 < >>>> chaselton at 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 at 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 >>>> >> >> >> >> >>>> >> >> >> >> 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 >>>> >> >> >> >> > >>>> >> >> >> >> > 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 >>>> >> >> >> >> >> >>>> >> >> >> >> >> 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 >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > 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 >> >>> > >>>> >> >> >> >> >> >> 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 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 >>>> >> >> >> >> >> >>>> >>>> >> >> >> >> >> >>>> wrote: >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >>Rossum >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> wrote: >>>> >> >> >> >> >> >>>>>> >>>> >> >> >> >> >> >>>>>> >>>> >> >> >> >> >> >>>>>> What I see in the strace: >>>> >> >> >> >> >> >>>>>> >>>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>>> >> >> >> >> >> >>>>>> ... load libm >>>> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do >something >>to it >>>> >> >> >> >> >> >>>>>> (what?) >>>> >> >> >> >> >> >>>>>> ... get current time >>>> >> >> >> >> >> >>>>>> ... allocate memory >>>> >> >> >> >> >> >>>>>> ... getuid >>>> >> >> >> >> >> >>>>>> ... segfault >>>> >> >> >> >> >> >>>>>> >>>> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't >>look as >>>> if >>>> >> >> >> >> >> >>>>>> it >>>> >> >> >> >> >> >>>>>> has >>>> >> >> >> >> >> >>>>>> started to >>>> >> >> >> >> >> >>>>>> load modules yet. >>>> >> >> >> >> >> >>>>>> >>>> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to >>me. >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >> >> >> >> >> >>>>> >>>> >>https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c > >-- >Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Sat Jan 31 20:15:08 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sat, 31 Jan 2015 13:15:08 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> References: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> Message-ID: <371EAB7B-4965-49AB-8CE7-479B5515B091@gmail.com> 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 < >>>>> chaselton at 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 at 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 >>>>> >> >> >> >> >>>>> >> >> >> >> 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 >>>>> >> >> >> >> > >>>>> >> >> >> >> > 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 >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> 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 >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > 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 >>> >>>> > >>>>> >> >> >> >> >> >> 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 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 >>>>> >> >> >> >> >> >>>> >>>>> >> >> >> >> >> >>>> wrote: >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >>>Rossum >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> >> >> >>>>> wrote: >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> What I see in the strace: >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>>>> >> >> >> >> >> >>>>>> ... load libm >>>>> >> >> >> >> >> >>>>>> ... open /dev/__properti -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Sat Jan 31 20:21:43 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sat, 31 Jan 2015 13:21:43 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> References: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> Message-ID: 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 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 < >>>>> chaselton at 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 at 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 >>>>> >> >> >> >> >>>>> >> >> >> >> 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 >>>>> >> >> >> >> > >>>>> >> >> >> >> > 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 >>>>> >> >> >> >> >> >>>>> >> >> >> >> >> 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 >>>>> >> >> >> >> >> > >>>>> >> >> >> >> >> > 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 >>> >>>> > >>>>> >> >> >> >> >> >> 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 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 >>>>> >> >> >> >> >> >>>> >>>>> >> >> >> >> >> >>>> wrote: >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >>>Rossum >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> >> >> >>>>> wrote: >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> What I see in the strace: >>>>> >> >> >> >> >> >>>>>> >>>>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>>>> >> >> >> >> >> >>>>>> ... load libm >>>>> >> >> >> >> >> >>>>>> ... open /dev/__properti -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sat Jan 31 20:09:22 2015 From: rymg19 at gmail.com (Ryan) Date: Sat, 31 Jan 2015 13:09:22 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: <7545e812-1a79-4389-8add-c0d6acdf03b3.maildroid@localhost> References: <7545e812-1a79-4389-8add-c0d6acdf03b3.maildroid@localhost> Message-ID: 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 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 at 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 >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 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 < >>> chaselton at 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 at 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 >>> >> >> >> >> >>> >> >> >> >> 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 >>> >> >> >> >> > >>> >> >> >> >> > 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 >>> >> >> >> >> >> >>> >> >> >> >> >> 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 >>> >> >> >> >> >> > >>> >> >> >> >> >> > 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 > >> > >>> >> >> >> >> >> >> 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 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 >>> >> >> >> >> >> >>>> >>> >> >> >> >> >> >>>> wrote: >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >Rossum >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> wrote: >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> What I see in the strace: >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>> >> >> >> >> >> >>>>>> ... load libm >>> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something >to it >>> >> >> >> >> >> >>>>>> (what?) >>> >> >> >> >> >> >>>>>> ... get current time >>> >> >> >> >> >> >>>>>> ... allocate memory >>> >> >> >> >> >> >>>>>> ... getuid >>> >> >> >> >> >> >>>>>> ... segfault >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't >look as >>> if >>> >> >> >> >> >> >>>>>> it >>> >> >> >> >> >> >>>>>> has >>> >> >> >> >> >> >>>>>> started to >>> >> >> >> >> >> >>>>>> load modules yet. >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to >me. >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>> >> >> >> >> >> >>>>> is the code that works with that file. >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks >like >>> >> >> >> >> >> >>>>> something >>> >> >> >> >> >> >>>>> to >>> >> >> >> >> >> >>>>> do >>> >> >> >> >> >> >>>>> with >>> >> >> >> >> >> >>>>> interprocess communication. Likely has nothing >to do >>> >> >> >> >> >> >>>>> with >>> >> >> >> >> >> >>>>> Python >>> >> >> >> >> >> >>>>> itself. >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> Maybe this would be useful? >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> That stack trace would be really helpful. >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> 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 >>> >> >> >> >> >> >>>>>>> >>> >> >> >> >> >> >>>>>>> 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 >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> wrote: >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> All, >>> >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port >Python >>> 2.7.8 >>> >> >> >> >> >> >>>>>>>>> to >>> >> >> >> >> >> >>>>>>>>> Android >>> >> >> >> >> >> >>>>>>>>> in >>> >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, >after >>> using >>> >> >> >> >> >> >>>>>>>>> the >>> >> >> >> >> >> >>>>>>>>> same >>> >> >> >> >> >> >>>>>>>>> configure >>> >> >> >> >> >> >>>>>>>>> options in the same environment, and >modifying >>> the >>> >> >> >> >> >> >>>>>>>>> setup.py >>> >> >> >> >> >> >>>>>>>>> as >>> >> >> >> >> >> >>>>>>>>> needed, >>> >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault >when >>> the >>> >> >> >> >> >> >>>>>>>>> generate-posix-vars >>> >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when >it is >>> >> >> >> >> >> >>>>>>>>> run >>> >> >> >> >> >> >>>>>>>>> as >>> >> >> >> >> >> >>>>>>>>> well >>> >> >> >> >> >> >>>>>>>>> (i.e. >>> >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m >sysconfig, or >>> >> >> >> >> >> >>>>>>>>> similar) >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a >bit >>> lost >>> >> >> >> >> >> >>>>>>>>> when >>> >> >> >> >> >> >>>>>>>>> reviewing >>> >> >> >> >> >> >>>>>>>>> it. >>> >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going >on...i.e. why >>> >> >> >> >> >> >>>>>>>>> Python >>> >> >> >> >> >> >>>>>>>>> 2.7 >>> >> >> >> >> >> >>>>>>>>> works but >>> >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> Thanks in advance, >>> >> >> >> >> >> >>>>>>>>> Cyd >>> >> >> >> >> >> >>>>>>>>> ________________________________ >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> Python-Dev mailing list >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> Python-Dev at python.org >>> >> >> >> >> >> >>>>>>>>> >>> https://mail.python.org/mailman/listinfo/python-dev >>> >> >> >> >> >> >>>>>>>>> Unsubscribe: >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >> >> >> >> >> >>>>>>>>> >>> >https://mail.python.org/mailman/options/python-dev/guido%40python.org >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> >>> >> >> >> >> >> >>>>>>>> -- >>> >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> -- >>> >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> ________________________________ >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> Python-Dev mailing list >>> >> >> >> >> >> >>>>>> Python-Dev at python.org >>> >> >> >> >> >> >>>>>> >>> https://mail.python.org/mailman/listinfo/python-dev >>> >> >> >> >> >> >>>>>> Unsubscribe: >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >> >> >> >> >> >>>>>> >>> >https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> >>> >> >> >> >> >> >>>>> -- >>> >> >> >> >> >> >>>>> Ryan >>> >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, >my >>> >> >> >> >> >> >>>>> answer >>> >> >> >> >> >> >>>>> will >>> >> >> >> >> >> >>>>> be >>> >> >> >> >> >> >>>>> simple: >>> >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. >Wait, I >>> >> >> >> >> >> >>>>> don't >>> >> >> >> >> >> >>>>> think >>> >> >> >> >> >> >>>>> that was >>> >> >> >> >> >> >>>>> nul-terminated." >>> >> >> >> >> >> >>>>> Personal reality distortion fields are immune >to >>> >> >> >> >> >> >>>>> contradictory >>> >> >> >> >> >> >>>>> evidence. >>> >> >> >> >> >> >>>>> - >>> >> >> >> >> >> >>>>> srean >>> >> >> >> >> >> >>>>> Check out my website: >http://kirbyfan64.github.io/ >>> >> >> >> >> >> >>> >>> >> >> >> >> >> >>> >>> >> >> >> >> >> >>> -- >>> >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please >>> excuse my >>> >> >> >> >> >> >>> brevity. >>> >> >> >> >> >> >>> Check out my website: >http://kirbyfan64.github.io/ >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > -- >>> >> >> >> >> > Ryan >>> >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my >answer >>> will >>> >> >> >> >> > be >>> >> >> >> >> > simple: >>> >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I >don't >>> think >>> >> >> >> >> > that >>> >> >> >> >> > was >>> >> >> >> >> > nul-terminated." >>> >> >> >> >> > Personal reality distortion fields are immune to >>> contradictory >>> >> >> >> >> > evidence. >>> >> >> >> >> > - >>> >> >> >> >> > srean >>> >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > 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 phone with K-9 Mail. Please excuse my brevity. Check out my website: http://kirbyfan64.github.io/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaselton at gmail.com Sat Jan 31 20:45:55 2015 From: chaselton at gmail.com (Cyd Haselton) Date: Sat, 31 Jan 2015 13:45:55 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <7545e812-1a79-4389-8add-c0d6acdf03b3.maildroid@localhost> Message-ID: 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 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 > >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 at 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 >>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 >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 < >>>> chaselton at 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 at 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 >>>> >> >> >> >> >>>> >> >> >> >> 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 >>>> >> >> >> >> > >>>> >> >> >> >> > 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 >>>> >> >> >> >> >> >>>> >> >> >> >> >> 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 >>>> >> >> >> >> >> > >>>> >> >> >> >> >> > 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 >> >>> > >>>> >> >> >> >> >> >> 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rymg19 at gmail.com Sat Jan 31 23:08:58 2015 From: rymg19 at gmail.com (Ryan Gonzalez) Date: Sat, 31 Jan 2015 16:08:58 -0600 Subject: [Python-Dev] Newly Built Python3 Binary Throws Segfault In-Reply-To: References: <3f23f67c-514e-4e91-89b2-5800ede08317@email.android.com> Message-ID: 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 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 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 < >>>>>> chaselton at 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 at 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 at 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 at 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 >>>>>> >> >> >> >> >>>>>> >> >> >> >> 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 >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > 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 >>>>>> >> >> >> >> >> >>>>>> >> >> >> >> >> 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 >>>>>> >> >> >> >> >> > >>>>>> >> >> >> >> >> > wrote: >>>>>> >> >> >> >> >> >> Absolutely. Good thing I have addr2line on device >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> /bld/python/Python-3.4.2 $ addr2line -C -f -e >>>>>> >> >> >> >> >> >> /lib/libpython3.4m.so.1.0 >>>>>> >> >> >> >> >> >> 0008bbc8 >>>>>> >> >> >> >> >> >> _PyMem_RawStrdup >>>>>> >> >> >> >> >> >> /bld/python/Python-3.4.2/Objects/obmalloc.c:323 >>>>>> >> >> >> >> >> >> /bld/python/Python-3.4.2 $ >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> >>>>>> >> >> >> >> >> >> On Thu, Jan 29, 2015 at 8:26 PM, Ryan < >>>>>> rymg19 at gmail.com> >>>>>> >> >> >> >> >> >> wrote: >>>>>> >> >> >> >> >> >>> Could you try the steps at >>>>>> >> >> >> >> >> >>> http://stackoverflow.com/a/11369475/2097780? They >>>>>> >> >> >> >> >> >>> allow you to get a better idea of where libc is >>>>>> crashing. >>>>>> >> >> >> >> >> >>> >>>>>> >> >> >> >> >> >>> Cyd Haselton 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 >>>>>> >> >> >> >> >> >>>> >>>>>> >> >> >> >> >> >>>> wrote: >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> On Wed, Jan 28, 2015 at 10:43 AM, Guido van >>>>>> Rossum >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> wrote: >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> What I see in the strace: >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> ... load libpython3.4m.so.1.0 >>>>>> >> >> >> >> >> >>>>>> ... load libm >>>>>> >> >> >> >> >> >>>>>> ... open /dev/__properties__ and do something >>>>>> to it >>>>>> >> >> >> >> >> >>>>>> (what?) >>>>>> >> >> >> >> >> >>>>>> ... get current time >>>>>> >> >> >> >> >> >>>>>> ... allocate memory >>>>>> >> >> >> >> >> >>>>>> ... getuid >>>>>> >> >> >> >> >> >>>>>> ... segfault >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> That's not a lot to go on, but it doesn't look >>>>>> as if >>>>>> >> >> >> >> >> >>>>>> it >>>>>> >> >> >> >> >> >>>>>> has >>>>>> >> >> >> >> >> >>>>>> started to >>>>>> >> >> >> >> >> >>>>>> load modules yet. >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> Does /dev/__properties__ ring a bell? Not to >>>>>> me. >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> https://android.googlesource.com/platform/system/core/+/tools_r22/init/property_service.c >>>>>> >> >> >> >> >> >>>>> is the code that works with that file. >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> This explains it a bit (slides 24-29). Looks >>>>>> like >>>>>> >> >> >> >> >> >>>>> something >>>>>> >> >> >> >> >> >>>>> to >>>>>> >> >> >> >> >> >>>>> do >>>>>> >> >> >> >> >> >>>>> with >>>>>> >> >> >> >> >> >>>>> interprocess communication. Likely has nothing >>>>>> to do >>>>>> >> >> >> >> >> >>>>> with >>>>>> >> >> >> >> >> >>>>> Python >>>>>> >> >> >> >> >> >>>>> itself. >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> Maybe this would be useful? >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> That stack trace would be really helpful. >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> On Wed, Jan 28, 2015 at 8:34 AM, Cyd Haselton >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> 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 >>>>>> >> >> >> >> >> >>>>>>> >>>>>> >> >> >> >> >> >>>>>>> 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 >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> wrote: >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> All, >>>>>> >> >> >> >> >> >>>>>>>>> I recently ditched my attempts to port >>>>>> Python 2.7.8 >>>>>> >> >> >> >> >> >>>>>>>>> to >>>>>> >> >> >> >> >> >>>>>>>>> Android >>>>>> >> >> >> >> >> >>>>>>>>> in >>>>>> >> >> >> >> >> >>>>>>>>> favor of Python 3.4.2. Unfortunately, >>>>>> after using >>>>>> >> >> >> >> >> >>>>>>>>> the >>>>>> >> >> >> >> >> >>>>>>>>> same >>>>>> >> >> >> >> >> >>>>>>>>> configure >>>>>> >> >> >> >> >> >>>>>>>>> options in the same environment, and >>>>>> modifying the >>>>>> >> >> >> >> >> >>>>>>>>> setup.py >>>>>> >> >> >> >> >> >>>>>>>>> as >>>>>> >> >> >> >> >> >>>>>>>>> needed, >>>>>> >> >> >> >> >> >>>>>>>>> the newly built binary throws a segfault >>>>>> when the >>>>>> >> >> >> >> >> >>>>>>>>> generate-posix-vars >>>>>> >> >> >> >> >> >>>>>>>>> portion of the build is reached...and when >>>>>> it is >>>>>> >> >> >> >> >> >>>>>>>>> run >>>>>> >> >> >> >> >> >>>>>>>>> as >>>>>> >> >> >> >> >> >>>>>>>>> well >>>>>> >> >> >> >> >> >>>>>>>>> (i.e. >>>>>> >> >> >> >> >> >>>>>>>>> ./python --help, ./python -E -S -m >>>>>> sysconfig, or >>>>>> >> >> >> >> >> >>>>>>>>> similar) >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> I took a strace of ./python, however I'm a >>>>>> bit lost >>>>>> >> >> >> >> >> >>>>>>>>> when >>>>>> >> >> >> >> >> >>>>>>>>> reviewing >>>>>> >> >> >> >> >> >>>>>>>>> it. >>>>>> >> >> >> >> >> >>>>>>>>> Any ideas as to what may be going on...i.e. >>>>>> why >>>>>> >> >> >> >> >> >>>>>>>>> Python >>>>>> >> >> >> >> >> >>>>>>>>> 2.7 >>>>>> >> >> >> >> >> >>>>>>>>> works but >>>>>> >> >> >> >> >> >>>>>>>>> 3.x throws a segfault? >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> Thanks in advance, >>>>>> >> >> >> >> >> >>>>>>>>> Cyd >>>>>> >> >> >> >> >> >>>>>>>>> ________________________________ >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> Python-Dev mailing list >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> Python-Dev at python.org >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>> >> >> >> >> >> >>>>>>>>> Unsubscribe: >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>>> >>>>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> >>>>>> >> >> >> >> >> >>>>>>>> -- >>>>>> >> >> >> >> >> >>>>>>>> --Guido van Rossum (python.org/~guido) >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> -- >>>>>> >> >> >> >> >> >>>>>> --Guido van Rossum (python.org/~guido) >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> ________________________________ >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> Python-Dev mailing list >>>>>> >> >> >> >> >> >>>>>> Python-Dev at python.org >>>>>> >> >> >> >> >> >>>>>> >>>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>>> >> >> >> >> >> >>>>>> Unsubscribe: >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> >> >> >> >> >> >>>>>> >>>>>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> >>>>>> >> >> >> >> >> >>>>> -- >>>>>> >> >> >> >> >> >>>>> Ryan >>>>>> >> >> >> >> >> >>>>> If anybody ever asks me why I prefer C++ to C, >>>>>> my >>>>>> >> >> >> >> >> >>>>> answer >>>>>> >> >> >> >> >> >>>>> will >>>>>> >> >> >> >> >> >>>>> be >>>>>> >> >> >> >> >> >>>>> simple: >>>>>> >> >> >> >> >> >>>>> "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. >>>>>> Wait, I >>>>>> >> >> >> >> >> >>>>> don't >>>>>> >> >> >> >> >> >>>>> think >>>>>> >> >> >> >> >> >>>>> that was >>>>>> >> >> >> >> >> >>>>> nul-terminated." >>>>>> >> >> >> >> >> >>>>> Personal reality distortion fields are immune to >>>>>> >> >> >> >> >> >>>>> contradictory >>>>>> >> >> >> >> >> >>>>> evidence. >>>>>> >> >> >> >> >> >>>>> - >>>>>> >> >> >> >> >> >>>>> srean >>>>>> >> >> >> >> >> >>>>> Check out my website: >>>>>> http://kirbyfan64.github.io/ >>>>>> >> >> >> >> >> >>> >>>>>> >> >> >> >> >> >>> >>>>>> >> >> >> >> >> >>> -- >>>>>> >> >> >> >> >> >>> Sent from my Android phone with K-9 Mail. Please >>>>>> excuse my >>>>>> >> >> >> >> >> >>> brevity. >>>>>> >> >> >> >> >> >>> Check out my website: http://kirbyfan64.github.io/ >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > >>>>>> >> >> >> >> > -- >>>>>> >> >> >> >> > Ryan >>>>>> >> >> >> >> > If anybody ever asks me why I prefer C++ to C, my >>>>>> answer will >>>>>> >> >> >> >> > be >>>>>> >> >> >> >> > simple: >>>>>> >> >> >> >> > "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I >>>>>> don't think >>>>>> >> >> >> >> > that >>>>>> >> >> >> >> > was >>>>>> >> >> >> >> > nul-terminated." >>>>>> >> >> >> >> > Personal reality distortion fields are immune to >>>>>> contradictory >>>>>> >> >> >> >> > evidence. >>>>>> >> >> >> >> > - >>>>>> >> >> >> >> > srean >>>>>> >> >> >> >> > Check out my website: http://kirbyfan64.github.io/ >>>>>> >> >> >> > >>>>>> >> >> >> > >>>>>> >> >> >> > >>>>>> >> >> >> > >>>>>> >> >> >> > -- >>>>>> >> >> >> > 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. > -- 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/ -------------- next part -------------- An HTML attachment was scrubbed... URL:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4