Re: [Python-Dev] new Plan 9 (and family) port of v2.7.5
On Tue, Jun 11, 2013 at 1:57 AM, Jeff Sickel wrote: > I have a set of patches I've developed based on the 2.7 branch that > provides a working port of Python 2.7.5 to Plan 9 386 and amd64 builds (an > arm version is mostly working, but will need a few more updates before > being hauled off on the wagon). Most of the changes, including mkfiles, > are local to a Plan9 subdirectory. There are a few changes to Lib/*.py > files specifically site.py and sysconfig.py to make living in a semi-POSIX > world tolerable with many current Python modules. > > Because Plan 9 does not have shared libraries, we must link in all the C > modules we want at build time. This means that I've included specific > targets to pull in Mercurial sources during the compilation and linking > phases. That brings us up to a current version of Mercurial 2.6.2. There > is no ssh support for cloning, but we do have a viable version of https: > using TLS/SSLv3 that has worked well with bitbucket. That said, I can > prepare a patch from my mq work area and submit it upstream in one of > various ways for review. > We have moved away from trying to support non-mainstream OSs directly in the code base and prefer people to maintain a patched branch elsewhere. That being said, if any of the changes are reasonable in general feel free to submit patches at bugs.python.org. > > Is there a preferred method that does not require an initial `hg clone > ssh://[email protected]/cpython`? > > Not quite sure what you mean, but I assume you are asking about submitting patches, in which case you can use an HTTPS clone. SSH access is only for core developers to push changes to the main repo. -Brett > acme# pwd > /usr/jas/src/cmd/cpython > acme# hg sum > parent: 83814:75a6bbf41cc8 plan9 qbase qtip > update setup base install locations > branch: 2.7 > commit: 8 unknown (clean) > update: 37 new changesets, 2 branch heads (merge) > mq: 1 applied > ac > > > -jas > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] Doubly linked lists in Python core?
I encountered this disconcerting message yesterday on a Linux system running Python 2.7.2: *** glibc detected *** /opt/local/bin/python: corrupted double-linked list: 0x03b01c90 *** Of course, no core file or other information about where the problem occurred was left behind, just the raw pointer value. Running under valgrind didn't report anything obvious, at least nothing different than a run with slightly different command line parameters which didn't elicit the message. I suspect the problem actually lies in one of our C++ libraries here at work, but before I attempt any debugging gymnastics (ow! my back hurts) I thought I would check to see if Python makes much use of double linked lists in a non-debug build. I don't recall a lot from days of yore, perhaps some in the dict implementation? Thanks, Skip ___ 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] Doubly linked lists in Python core?
2013/6/11 Skip Montanaro : > I encountered this disconcerting message yesterday on a Linux system > running Python 2.7.2: > > *** glibc detected *** /opt/local/bin/python: corrupted double-linked > list: 0x03b01c90 *** I suspect that's a corrupt linked list interal to glibc. -- Regards, Benjamin ___ 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] Doubly linked lists in Python core?
On Tue, 2013-06-11 at 12:14 -0700, Benjamin Peterson wrote: > 2013/6/11 Skip Montanaro : > > I encountered this disconcerting message yesterday on a Linux system > > running Python 2.7.2: > > > > *** glibc detected *** /opt/local/bin/python: corrupted double-linked > > list: 0x03b01c90 *** > > I suspect that's a corrupt linked list interal to glibc. Yes: almost certainly the one inside glibc's implementation of malloc. Somewhere in the process you have a double-free, or a buffer overrun that's splatting the links that live in memory between the allocated bufffers. You may want to try running the process under valgrind. Hope this is helpful Dave ___ 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] Doubly linked lists in Python core?
> You may want to try running the process under valgrind. Thanks. I'm trying that but have been so far unable to get valgrind to report any problems within Python or our libraries before that message, just a couple things at startup which seem to occur before Python gets going: ==21374== Invalid read of size 1 ==21374==at 0x4C2DEA9: putenv (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21374==by 0x400E71: append_env_vars (binary-wrapper-main.c:175) ==21374==by 0x4008CA: set_binary_wrapper_env (c-python-wrapper.c:58) ==21374==by 0x40168D: main (binary-wrapper-main.c:382) ==21374== Address 0x51d6a84 is 0 bytes after a block of size 52 alloc'd ==21374==at 0x4C2ACCE: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21374==by 0x400E61: append_env_vars (binary-wrapper-main.c:173) ==21374==by 0x4008CA: set_binary_wrapper_env (c-python-wrapper.c:58) ==21374==by 0x40168D: main (binary-wrapper-main.c:382) ==21374== ==21374== Syscall param execve(envp[i]) points to unaddressable byte(s) ==21374==at 0x4EE7067: execve (in /lib64/libc-2.15.so) ==21374==by 0x4016AA: main (binary-wrapper-main.c:385) ==21374== Address 0x51d6a84 is 0 bytes after a block of size 52 alloc'd ==21374==at 0x4C2ACCE: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21374==by 0x400E61: append_env_vars (binary-wrapper-main.c:173) ==21374==by 0x4008CA: set_binary_wrapper_env (c-python-wrapper.c:58) ==21374==by 0x40168D: main (binary-wrapper-main.c:382) Skip ___ 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
