[Python-Dev] possible bug in distutils (Mingw32CCompiler)?
Mingw32CCompiler in cygwincompiler.py emits the symbol -mno-cygwin. This is used to make Cygwin's gcc behave as mingw. As of gcc 4.6 it is not recognized by the mingw gcc compiler itself, and causes as crash. It should be removed because it is never needed for mingw (in any version), only for cross-compilation to mingw from other gcc versions. Instead, those who use CygwinCCompiler or Linux GCC to "cross-compile" to plain Win32 can set -mno-cygwin manually. It also means -mcygwin should be removed from the output of CygwinCCompiler. I think... Sturla ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Added examples.
On Thu, May 24, 2012 at 8:10 PM, eric.smith wrote:
> + Lib/test/namspace_pkgs
Typo: s/namspace/namespace/
> +Here we add the parent directories to ``sys.path``, and show that the
> +portions are correctly found::
> +
> + >>> import sys
> + >>> sys.path += ['Lib/test/namespace_pkgs/parent1/parent',
> 'Lib/test/namespace_pkgs/parent2/parent']
The trailing "/parent" shouldn't be there on either of these paths.
The comments that refer back to these also need the same adjustment.
> + Lib/test/namspace_pkgs
Same typo as above.
> + # add the first two parent paths to sys.path
> + >>> import sys
> + >>> sys.path += ['Lib/test/namespace_pkgs/parent1/parent',
> 'Lib/test/namespace_pkgs/parent2/parent']
Again, need to lose the last directory from these paths and the
comments that refer to them.
> + # now add parent3 to the parent's __path__:
> + >>> parent.__path__.append('Lib/test/namespace_pkgs/parent3/parent')
This modification is incorrect, it should be:
sys.path.append('Lib/test/namespace_pkgs/parent3')
and both parent.__path__ and parent.child.__path__ should pick up
their extra portions on the next import attempt.
Also, I suggest renaming "parent1", "parent2" and "parent3" to
"project1", "project2" and "project3".
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible bug in distutils (Mingw32CCompiler)?
On Thu, May 24, 2012 at 7:03 AM, Sturla Molden wrote: > > Mingw32CCompiler in cygwincompiler.py emits the symbol -mno-cygwin. > > This is used to make Cygwin's gcc behave as mingw. As of gcc 4.6 it is not > recognized by the mingw gcc compiler itself, and causes as crash. It should > be removed because it is never needed for mingw (in any version), only for > cross-compilation to mingw from other gcc versions. > > Instead, those who use CygwinCCompiler or Linux GCC to "cross-compile" to > plain Win32 can set -mno-cygwin manually. It also means -mcygwin should be > removed from the output of CygwinCCompiler. > > I think... Please report bugs to http://bugs.python.org so they don't get lost in email. The relevant people will be notified or assigned if a bug is entered. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible bug in distutils (Mingw32CCompiler)?
On Thu, 24 May 2012 08:45:30 -0500, Brian Curtin wrote: > On Thu, May 24, 2012 at 7:03 AM, Sturla Molden wrote: > > > > Mingw32CCompiler in cygwincompiler.py emits the symbol -mno-cygwin. > > > > This is used to make Cygwin's gcc behave as mingw. As of gcc 4.6 it is not > > recognized by the mingw gcc compiler itself, and causes as crash. It should > > be removed because it is never needed for mingw (in any version), only for > > cross-compilation to mingw from other gcc versions. > > > > Instead, those who use CygwinCCompiler or Linux GCC to "cross-compile" to > > plain Win32 can set -mno-cygwin manually. It also means -mcygwin should be > > removed from the output of CygwinCCompiler. > > > > I think... > > Please report bugs to http://bugs.python.org so they don't get lost in > email. The relevant people will be notified or assigned if a bug is > entered. It was already reported by someone else: http://bugs.python.org/issue12641 --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale
I've reviewed the updates to the PEP and have accepted it. Congrats all! I know the implementation is lagging behind a bit, that's not a problem. Just get it into the next 3.3 alpha release! -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale
On 5/24/2012 2:33 PM, Guido van Rossum wrote: > I've reviewed the updates to the PEP and have accepted it. Congrats all! Thanks to the many people who helped: Martin, Barry, Guido, Jason, Nick, PJE, and others. I'm sure I've offended someone by leaving them out, and I apologize in advance. But special thanks to Brett. Without his work on importlib, this never would have happened (as Barry, Jason, and I demonstrated on a two or three occasions)! > I know the implementation is lagging behind a bit, that's not a > problem. Just get it into the next 3.3 alpha release! It's only missing a few small things. I'll get it committed in the next day or so. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] An infinite loop in dictobject.c
Hello all. I seem to be encountering somewhat rare an infinite loop
in hash table probing while importing _socket, as triggered by
init_socket.c in Python 2.6, as seen/patched shipped with Ubuntu 10.04
LTS. The problem only reproduces on 32 bit machines, on both -O2 and
-O0 builds (which is how I have managed to retrieve the detailed stack
traces below). To cut to the chase, the bottom of the stack trace
invariably looks like this, in particular the "key" (and therefore
"hash") value is always the same:
#0 0x08088637 in lookdict_string (mp=0xa042714, key='SO_RCVTIMEO',
hash=612808203) at ../Objects/dictobject.c:421
#1 0x080886cd in insertdict (mp=0xa042714, key='SO_RCVTIMEO', hash=612808203,
value=20) at ../Objects/dictobject.c:450
#2 0x08088cac in PyDict_SetItem (op=, key=
'SO_RCVTIMEO', value=20) at ../Objects/dictobject.c:701
#3 0x0808b8d4 in PyDict_SetItemString (v=
{'AF_INET6': 10, 'SocketType': ,
'getaddrinfo': ,
'TIPC_MEDIUM_IMPORTANCE': 1, 'htonl': ,
'AF_UNSPEC': 0, 'TIPC_DEST_DROPPABLE': 129, 'TIPC_ADDR_ID': 3,
'PF_PACKET': 17, 'AF_WANPIPE': 25, 'PACKET_OTHERHOST': 3, 'AF_AX25':
3, 'PACKET_BROADCAST': 1, 'PACKET_FASTROUTE': 6, 'TIPC_NODE_SCOPE': 3,
'inet_pton': , 'AF_ATMPVC': 8,
'NETLINK_IP6_FW': 13, 'NETLINK_ROUTE': 0, 'TIPC_PUBLISHED': 1,
'TIPC_WITHDRAWN': 2, 'AF_ECONET': 19, 'AF_LLC': 26, '__name__':
'_socket', 'AF_NETROM': 6, 'SOCK_RDM': 4, 'AF_IRDA': 23, 'htons':
, 'SOCK_RAW': 3, 'inet_ntoa': , 'AF_NETBEUI': 13, 'AF_NETLINK': 16,
'TIPC_WAIT_FOREVER': -1, 'AF_UNIX': 1, 'TIPC_SUB_PORTS': 1,
'HCI_TIME_STAMP': 3, 'gethostbyname_ex': , 'SO_RCVBUF': 8, 'AF_APPLETALK': 5,
'SOCK_SEQPACKET': 5, 'AF_DECnet': 12, 'PACKET_OUTGOING': 4,
'SO_SNDLOWAT': 19, 'TIPC_SRC_DROPPABLE':...(truncated), key=0x81ac5fb
"SO_RCVTIMEO", item=20) at ../Objects/dictobject.c:2301
#4 0x080f6c98 in PyModule_AddObject (m=, name=
0x81ac5fb "SO_RCVTIMEO", o=20) at ../Python/modsupport.c:615
#5 0x080f6d0b in PyModule_AddIntConstant (m=,
name=0x81ac5fb "SO_RCVTIMEO", value=20) at ../Python/modsupport.c:627
#6 0x081321fd in init_socket () at ../Modules/socketmodule.c:4708
Here, we never escape from lookdict_string. The key is not in the
dictionary, but at this stage Python is trying to figure out that is
the case, and cannot seem to exit because of the lack of a dummy
entry. Furthermore, every single reproduced case has a dictionary
with a suspicious looking violation of an invariant that I believe is
communicated by the source of dictobject.c, with emphasis on the
values of ma_fill, ma_used, and ma_mask, which never deviate in any
reproduced case. It seems like no hash table should ever get this
full, per the comments in the source:
$3 = {ob_refcnt = 1, ob_type = 0x81c3aa0, ma_fill = 128, ma_used = 128,
ma_mask = 127, ma_table = 0xa06b4a8, ma_lookup =
0x8088564 , ma_smalltable = {{me_hash = 0, me_key = 0x0,
me_value = 0x0}, {me_hash = 1023053529, me_key = '__name__', me_value =
'_socket'}, {me_hash = 1679430097, me_key = 'gethostbyname', me_value =
}, {me_hash = 0, me_key = 0x0, me_value =
0x0}, {me_hash = 779452068, me_key = 'gethostbyname_ex', me_value =
}, {me_hash = -322108099, me_key =
'__doc__', me_value = None}, {me_hash = -1649837379, me_key =
'gethostbyaddr', me_value = }, {
me_hash = 1811348911, me_key = '__package__', me_value = None}}}
The Python program that is running afoul this bug is using gevent, but
the stack traces suggest that all gevent is doing at the time this
crashes is importing "socket", and this is done at the very, very
beginning of program execution.
Finally, what's especially strange is that I had gone a very long time
running this exact version of Python, libraries, and application quite
frequently: it suddenly started cropping up a little while ago (maybe
a few weeks). It could have been just coincidence, but if there are
code paths in init_socket.c that may somehow be sensitive to the
network somehow, this could have been related. I also have a limited
suspicion that particularly unlucky OOM (these systems are configured
in a way where malloc and friends will return NULL, i.e. no overcommit
on Linux) could be related.
Any guiding words, known bugs, or suspicions?
--
fdr
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
Daniel Farina wrote: Hello all. I seem to be encountering somewhat rare an infinite loop in hash table probing while importing _socket, as triggered by init_socket.c in Python 2.6, as seen/patched shipped with Ubuntu 10.04 LTS. The problem only reproduces on 32 bit machines, on both -O2 and -O0 builds (which is how I have managed to retrieve the detailed stack Please submit a report to the tracker for this. (Add me to the nosy list if you can) Cheers, Mark. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
If it only started happening recently, suspicion would naturally fall on the hash randomisation security fix (as I assume a new version of Python would have been pushed for 10.04 with that update) Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale
On Thu, May 24, 2012 at 12:33 PM, Guido van Rossum wrote: > I've reviewed the updates to the PEP and have accepted it. Congrats all! Congrats! -eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Added examples.
On May 24, 2012 11:29 PM, "Eric V. Smith" wrote: > > Possibly I am being too tricky here by modifying parent.__path__, and I > should just modify sys.path again, as you suggest. But I was trying to > show that modifying parent.__path__ will also work. Modifying namespace package __path__ attributes directly seems like a good way to accidentally break the auto-updating. We probably don't want to encourage that. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On Thu, May 24, 2012 at 1:07 PM, Nick Coghlan wrote: > If it only started happening recently, suspicion would naturally fall on the > hash randomisation security fix (as I assume a new version of Python would > have been pushed for 10.04 with that update) I do not think so; I do not see in in the backpatches made to 2.6.5 (http://packages.ubuntu.com/lucid/python2.6), unless they are particularly slick. -- fdr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On Thu, 24 May 2012 12:11:58 -0700 Daniel Farina wrote: > > Finally, what's especially strange is that I had gone a very long time > running this exact version of Python, libraries, and application quite > frequently: it suddenly started cropping up a little while ago (maybe > a few weeks). Do you mean it's a hand-compiled Python? Are you sure you didn't recompile it / update to a later version recently? If you didn't change anything, this may be something unrelated to Python, such as a hardware problem. You are right that ma_fill == ma_used should, AFAIK, never happen. Perhaps you could add conditional debug statements when that condition happens, to know where it comes from. Furthermore, if this is a hand-compiled Python, you could reconfigure it --with-pydebug, so as to enable more assertions in the interpreter core (this will make it quite a bit slower too :-)). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On Thu, May 24, 2012 at 12:59 PM, Mark Shannon wrote: > Please submit a report to the tracker for this. > (Add me to the nosy list if you can) http://bugs.python.org/issue14903 However, I cannot add you to the nosy list, as you do not show up in the search. -- fdr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On May 25, 2012, at 06:07 AM, Nick Coghlan wrote: >If it only started happening recently, suspicion would naturally fall on >the hash randomisation security fix (as I assume a new version of Python >would have been pushed for 10.04 with that update) I do not think the hash randomization patch has been pushed to Python 2.6 in Lucid 10.04.4 yet, which still has Python 2.6.5 (plus patches, but not that one). -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On Thu, May 24, 2012 at 1:15 PM, Antoine Pitrou wrote: > On Thu, 24 May 2012 12:11:58 -0700 > Daniel Farina wrote: >> >> Finally, what's especially strange is that I had gone a very long time >> running this exact version of Python, libraries, and application quite >> frequently: it suddenly started cropping up a little while ago (maybe >> a few weeks). > > Do you mean it's a hand-compiled Python? Are you sure you didn't > recompile it / update to a later version recently? Quite sure. It was vanilla Ubuntu, and then I side-graded it to vanilla ubuntu at -O0. > If you didn't change anything, this may be something unrelated to > Python, such as a hardware problem. Occurs on a smattering of a large number of systems more or less at random. Seems unlikely. > You are right that ma_fill == ma_used should, AFAIK, never happen. > Perhaps you could add conditional debug statements when that condition > happens, to know where it comes from. > > Furthermore, if this is a hand-compiled Python, you could reconfigure > it --with-pydebug, so as to enable more assertions in the interpreter > core (this will make it quite a bit slower too :-)). Yes, this is my next step, although I am going to do a bit more whacking of the interpreter as to pause rather than crash when it encounters this problem. -- fdr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On 5/24/2012 4:20 PM, Daniel Farina wrote: On Thu, May 24, 2012 at 12:59 PM, Mark Shannon wrote: Please submit a report to the tracker for this. (Add me to the nosy list if you can) http://bugs.python.org/issue14903 However, I cannot add you to the nosy list, as you do not show up in the search. The nosy list box search only shows people with commit privileges. Others you have to find them in the User List accessible from the sidebar, but that may be admin only for all I know. Anyway, Mark should have said 'as Mark.Shannon'. I have added him on the issue. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] An infinite loop in dictobject.c
On Fri, May 25, 2012 at 6:23 AM, Daniel Farina wrote: >> Furthermore, if this is a hand-compiled Python, you could reconfigure >> it --with-pydebug, so as to enable more assertions in the interpreter >> core (this will make it quite a bit slower too :-)). > > Yes, this is my next step, although I am going to do a bit more > whacking of the interpreter as to pause rather than crash when it > encounters this problem. You may also want to give Victor's faulthandler module a try: http://pypi.python.org/pypi/faulthandler/ Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] VS 11 Express is Metro only.
The free Visual Studio 11 Express for Windows 8 (still in beta) will produce both 32 and 64 bit binaries and allow multiple languages but will only produce Metro apps. For desktop apps, either the paid Visual Studio versions or the free 2010 Express releases are required. https://www.microsoft.com/visualstudio/11/en-us/products/express bottom of page. Will this inhibit someday moving to Visual Studio 11 Professional or would VS2010 Express or VC++2010 Express still work for hacking on Python or making extensions that would work with any VS11-produced binary? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 11 Express is Metro only.
On Thu, May 24, 2012 at 5:21 PM, Terry Reedy wrote: > The free Visual Studio 11 Express for Windows 8 (still in beta) will produce > both 32 and 64 bit binaries and allow multiple languages but will only > produce Metro apps. For desktop apps, either the paid Visual Studio versions > or the free 2010 Express releases are required. > https://www.microsoft.com/visualstudio/11/en-us/products/express > bottom of page. > > Will this inhibit someday moving to Visual Studio 11 Professional or would > VS2010 Express or VC++2010 Express still work for hacking on Python or > making extensions that would work with any VS11-produced binary? I don't know. Maybe? Windows 8 and VS11 are still not released so who knows what will happen. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] VS 11 Express is Metro only.
The free Visual Studio 11 Express for Windows 8 (still in beta) will produce both 32 and 64 bit binaries and allow multiple languages but will only produce Metro apps. For desktop apps, either the paid Visual Studio versions or the free 2010 Express releases are required. https://www.microsoft.com/visualstudio/11/en-us/products/express bottom of page. Will this inhibit someday moving to Visual Studio 11 Professional or would VS2010 Express or VC++2010 Express still work for hacking on Python or making extensions that would work with any VS11-produced binary? I think it's too early to guess what the final release of Visual Studio 11 Express will or will not include. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
