[Python-Dev] Python tests fails on HP-UX 11.11 and core dumps
Hello Experts,
I tried
python -4.2.1 on a HP-UX 11.11 PA machine. I was able to
python. Gmake passes, gmake test results in
error. The python reported
that test_pty fails,when running this
test alone.
Can anyone help to find why core dumps at running
the test_subprocess.py test.
Also how can I solve it?
Have anyone faced the same problem
earlier.
The details are given below;
# ../../python
test_pty.pyCalling master_open()Got master_fd '3', slave_name
'/dev/pts/0'Calling slave_open('/dev/pts/0')Got slave_fd
'4'Traceback (most recent call last): File "test_pty.py", line 58,
in ? test_basic_pty() File "test_pty.py", line
29, in test_basic_pty if not
os.isatty(slave_fd): File "test_pty.py", line 50, in
handle_sig raise TestFailed, "isatty
hung"test.test_support.TestFailed: isatty hung#
# ../../python
test_subprocess.pytest_args_string (__main__.ProcessTestCase) ...
oktest_call_kwargs (__main__.ProcessTestCase) ... oktest_call_seq
(__main__.ProcessTestCase) ... oktest_call_string (__main__.ProcessTestCase)
... oktest_communicate (__main__.ProcessTestCase) ...
oktest_communicate_pipe_buf (__main__.ProcessTestCase) ...
oktest_communicate_returns (__main__.ProcessTestCase) ... oktest_cwd
(__main__.ProcessTestCase) ... oktest_env (__main__.ProcessTestCase) ...
oktest_exceptions (__main__.ProcessTestCase) ... oktest_executable
(__main__.ProcessTestCase) ... oktest_invalid_args
(__main__.ProcessTestCase) ... oktest_invalid_bufsize
(__main__.ProcessTestCase) ... oktest_list2cmdline
(__main__.ProcessTestCase) ... oktest_no_leaking (__main__.ProcessTestCase)
... oktest_poll (__main__.ProcessTestCase) ... oktest_preexec
(__main__.ProcessTestCase) ... oktest_run_abort (__main__.ProcessTestCase)
... oktest_shell_sequence (__main__.ProcessTestCase) ...
oktest_shell_string (__main__.ProcessTestCase) ... oktest_stderr_filedes
(__main__.ProcessTestCase) ... oktest_stderr_fileobj
(__main__.ProcessTestCase) ... oktest_stderr_none (__main__.ProcessTestCase)
... oktest_stderr_pipe (__main__.ProcessTestCase) ...
oktest_stdin_filedes (__main__.ProcessTestCase) ... oktest_stdin_fileobj
(__main__.ProcessTestCase) ... oktest_stdin_none (__main__.ProcessTestCase)
... oktest_stdin_pipe (__main__.ProcessTestCase) ...
oktest_stdout_filedes (__main__.ProcessTestCase) ...
oktest_stdout_fileobj (__main__.ProcessTestCase) ...
ok this bit of output is from a test of stdout in
a different process ...test_stdout_none (__main__.ProcessTestCase)
... oktest_stdout_pipe (__main__.ProcessTestCase) ...
oktest_stdout_stderr_file (__main__.ProcessTestCase) ...
oktest_stdout_stderr_pipe (__main__.ProcessTestCase) ...
oktest_universal_newlines (__main__.ProcessTestCase) ...
oktest_universal_newlines_communicate (__main__.ProcessTestCase) ...
oktest_wait (__main__.ProcessTestCase) ...
oktest_writes_before_communicate (__main__.ProcessTestCase) ...
ok
--Ran
38 tests in 8.171s
Analysing the core file through GDB;
# gdb ../../python coreHP gdb 4.5 for PA-RISC
1.1 or 2.0 (narrow), HP-UX 11.00and target
hppa1.1-hp-hpux11.00.Copyright 1986 - 2001 Free Software Foundation,
Inc.Hewlett-Packard Wildebeest 4.5 (based on GDB) is covered by theGNU
General Public License. Type "show copying" to see the conditions tochange
it and/or distribute copies. Type "show warranty" for
warranty/support...Core was generated by `python'.Program terminated
with signal 6, Aborted.#0 0xc020bad0 in kill+0x10 () from
/usr/lib/libc.2(gdb) bt#0 0xc020bad0 in kill+0x10 () from
/usr/lib/libc.2#1 0xc01a655c in raise+0x24 () from
/usr/lib/libc.2#2 0xc01e69a8 in abort_C+0x160 () from
/usr/lib/libc.2#3 0xc01e6a04 in abort+0x1c () from
/usr/lib/libc.2#4 0xffbe4 in posix_abort (self=0x40029098, noargs=0x0)
at ./Modules/posixmodule.c:7158#5 0xc9b7c in PyEval_EvalFrame
(f=0x40028e54) at Python/ceval.c:3531#6 0xc01a655c in raise+0x24 ()
from /usr/lib/libc.2#7 0x475b0 in freechildren (n=0x0) at
Parser/node.c:131(gdb)
Build Environment;
GCC - gcc version 3.4.3
HP-UX omega B.11.11 U 9000/800
./configure --prefix=/opt/iexpress/python
--disable-ipv6 --with-signal-module --with-threads
Earlier, I faced problem while gmake, and make
changes as per the following link;
https://sourceforge.net/tracker/?func=detailatid=105470aid=1071597group_id=5470
And I was able to build Python
succesfully.
Also, the overall result of tests
are;
250 tests OK.1 test
failed: test_pty39 tests
skipped: test_aepack test_al test_applesingle test_bsddb
test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl
test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp
test_codecmaps_kr test_codecmaps_tw test_curses test_dl
test_gdbm test_gl test_imgfile test_largefile
test_linuxaudiodev test_locale test_macfs test_macostools
test_nis test_normalization test_ossaudiodev test_pep277
test_plistlib test_scriptpackages test_socket_ssl
test_socketserver test_sunaudiodev test_tcl test_timeout
Re: [Python-Dev] Security capabilities in Python
On Sun, 10 Apr 2005, Eyal Lotem wrote: It may be really hard to get it right, unless we are overlooking some simple solution. To get it right, you at least need to know exactly what your operators mean. I messed up because i failed to realize that '==' can be redefined, and 'in' depends on '==' to work properly. What about implementing the facet in C? This could avoid the class of problems you have just mentioned. I don't think that's a good solution. A facet is just one basic programming pattern that you can build in a capability system; it would be silly to have to go back to C every time you wanted to build some other construct. A better way would be to start with capabilities that behave simply and correctly; then you can build whatever you want. -- ?!ng ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unified or context diffs?
Are context diffs still favoured for patches? The patch submission guidelines [1] still say that, but is it actually true these days? I personally prefer unified diffs, but have been generating context diffs because of what the guidelines say. Brett can probably guess why I'm asking :) Cheers, Nick. [1] http://www.python.org/patches/ -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] super_getattro() Behaviour
In PyQt, wrapped types implement lazy access to the type dictionary through tp_getattro. If the normal attribute lookup fails, then private tables are searched and the attribute (if found) is created on the fly and returned. It is also put into the type dictionary so that it is found next time through the normal lookup. This is done to speed up the import of, and the memory consumed by, the qt module which contains thousands of class methods. This all works fine - except when super is used. The implementation of super_getattro() doesn't use the normal attribute lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO hierarchy itself and searches instance dictionaries explicitly. This means that attributes that have not yet been referenced (ie. not yet been cached in the type dictionary) will not be found. Questions... 1. What is the reason why it doesn't go via tp_getattro? Bug or feature? 2. A possible workaround is to subvert the ma_lookup function of the type dictionary after creating the type to do something similar to what my tp_getattro function is doing. Are there any inherent problems with that? 3. Why, when creating a new type and eventually calling type_new() is a copy of the dictionary passed in made? Why not take a reference to it? This would allow a dict sub-class to be used as the type dictionary. I could then implement a lazy-dict sub-class with the behaviour I need. 4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) Many thanks, Phil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IPV6 with Python- 4.2.1 on HPUX
Hi Experts, I am pretty new to Python. I have been trying to compile python on HP-UX 11.23 IPF machine. I tried to build with following configure option. ./configure --prefix=/opt/iexpress/python --enable-ipv6 --with-signal-module --with-threads machine info : HP-UX beta B.11.23 U ia64 gcc : gcc version 3.4.3 While configure, I faced the following pbm, checking ipv6 stack type... ./configure[13033]: /usr/xpg4/bin/grep: not found.unknown Then I checked the config.log to find the entires for IPV6; configure:12811: checking if --enable-ipv6 is specifiedconfigure:12822: result: yesconfigure:12954: checking ipv6 stack typeconftest.c:78:22: features.h: No such file or directoryconftest.c:78:48: /usr/local/v6/include/sys/v6config.h: No such file or directoryconfigure:13111: result: unknown But, configure didnot produce any error mesage. So plz advice whether Python supports the IPV6 option on HP-UX. Bez, I know ipv6 differs from linux and HP-UX. If I no need to worry about this and build python. How to check whether IPV6 option works well with my python. Anyone please help to how to test the IPV6 functionality test. Is there any specific IPV6 test available with python. I could not find any specific testsuit for IPV6 under test directory. Plz share ur comments Advance Thanks, Senthil Prabu.S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Unified or context diffs?
[Nick Coghlan] Are context diffs still favoured for patches? The patch submission guidelines [1] still say that, but is it actually true these days? I personally prefer unified diffs, but have been generating context diffs because of what the guidelines say. Submit whichever is the most informative. For some changes, it is easier to see the changed lines immediately above and below each other. For others, it helps to be able to see the whole algorithm. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unified or context diffs?
Raymond Hettinger wrote: [Nick Coghlan] Are context diffs still favoured for patches? The patch submission guidelines [1] still say that, but is it actually true these days? I personally prefer unified diffs, but have been generating context diffs because of what the guidelines say. Submit whichever is the most informative. For some changes, it is easier to see the changed lines immediately above and below each other. For others, it helps to be able to see the whole algorithm. And for the 'patch' tool, it doesn't really matter what you use, right? --Irmen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unified or context diffs?
Nick Coghlan wrote: Are context diffs still favoured for patches? Just for the record: I also prefer unified over context diffs. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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 tests fails on HP-UX 11.11 and core dumps
Senthil Prabu.S wrote: I tried python -4.2.1 on a HP-UX 11.11 PA machine. I was able to python. Gmake passes, gmake test results in error. The python reported that test_pty fails,when running this test alone. Can anyone help to find why core dumps at running the *test_subprocess.py* test. Also how can I solve it? Please understand that python-dev is not the place to get free consulting. If you are willing to investigate somewhat further, try to understand the problem, and propose patches, then I would be willing to review the patches, comment on their correctness, and perhaps integrate them into the Python CVS. As it stands, I can personally take no more time to help with HP-UX problems for the near future (say, ten years :-) I do recall that there are serious problems with pseudo-terminals in Python and HP-UX, so yes, we have heard of this before. If I knew a solution, it were applied to Python already. Please understand that this perhaps hostile-sounding response is just my personal view; if somebody else responds more gracefully, just ignore me. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] super_getattro() Behaviour
Phil Thompson [EMAIL PROTECTED] writes: In PyQt, wrapped types implement lazy access to the type dictionary through tp_getattro. If the normal attribute lookup fails, then private tables are searched and the attribute (if found) is created on the fly and returned. It is also put into the type dictionary so that it is found next time through the normal lookup. This is done to speed up the import of, and the memory consumed by, the qt module which contains thousands of class methods. This all works fine - except when super is used. The implementation of super_getattro() doesn't use the normal attribute lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO hierarchy itself and searches instance dictionaries explicitly. This means that attributes that have not yet been referenced (ie. not yet been cached in the type dictionary) will not be found. Questions... 1. What is the reason why it doesn't go via tp_getattro? Because it wouldn't work if it did? I'm not sure what you're suggesting here. 2. A possible workaround is to subvert the ma_lookup function of the type dictionary after creating the type to do something similar to what my tp_getattro function is doing. Eek! Are there any inherent problems with that? Well, I think the layout of dictionaries is fiercely private. IIRC, the only reason it's in a public header is to allow some optimzations in ceval.c (though this isn't at all obvious from the headers, so maybe I'm mistaken). 3. Why, when creating a new type and eventually calling type_new() is a copy of the dictionary passed in made? I think this is to prevent changes to tp_dict behind the type's back. It's important to keep the dict and the slots in sync. Why not take a reference to it? This would allow a dict sub-class to be used as the type dictionary. I could then implement a lazy-dict sub-class with the behaviour I need. Well, not really, because super_getattro uses PyDict_GetItem, which doesn't respect subclasses... 4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) Hum, I can't think of one, I'm afraid. There has been some vague talk of having a tp_lookup slot in typeobjects, so PyDict_GetItem(t-tp_dict, x); would become t-tp_lookup(x); (well, ish, it might make more sense to only do that if the dict lookup fails). For now, not being lazy seems your only option :-/ (it's what PyObjC does). Cheers, mwh -- Many of the posts you see on Usenet are actually from moths. You can tell which posters they are by their attraction to the flames. -- Internet Oracularity #1279-06 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IPV6 with Python- 4.2.1 on HPUX
On Wednesday 13 April 2005 21:11, Senthil Prabu.S wrote: Hi Experts, I am pretty new to Python. I have been trying to compile python on HP-UX 11.23 IPF machine. I tried to build with following configure option. ./configure --prefix=/opt/iexpress/python --enable-ipv6 --with-signal-module --with-threads machine info : HP-UX beta B.11.23 U ia64 gcc : gcc version 3.4.3 While configure, I faced the following pbm, Last time I tried, gcc on HPUX/ia64 was completely unable to build a working version of Python - this was not the fault of Python, but simply that gcc on that platform was utterly broken. Please try with the HP compiler instead, see if that is any better. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
