[issue2020] _sha256 module missing if openssl is not in a "normal" directory.
New submission from Peter Saunders: When compiling python 2.5.1 on Solaris 10 (sparc and x86), with openssl 0.9.8e - test_md5 fails with No module named _sha256. (As does doing an "import md5") When compiling, setup.dist was modified, the ssl parts were uncommented, and modified to use the directory that we have ssl installed in. SSL=/opt/IB _ssl _ssl.c \ -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \ -L$(SSL)/lib -R$(SSL)/lib -lssl -lcrypto The compiling env (on sol x86): CC=cc CFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic CPPFLAGS=-I/opt/IB/include CXX=CC CXXFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic LDFLAGS=-L/opt/IB/lib -R/opt/IB/lib LD_RUN_PATH=/opt/IB/lib PATH=/usr/bin:/sbin:/usr/sbin:/opt/IB/bin:/usr/ccs/bin:/opt/SUNWspro/bin configure --prefix=/opt/IBpython/2.5.1 --without-gcc --with-threads However, if I modify setup.py, and replace every occurrence of "/usr/local" with "/opt/IB" (we don't use /usr/local) - then it compiles fine, and the md5 module works correctly. Is it possible for this to be made a configure argument, or a environment setting? -- components: Build messages: 62101 nosy: [EMAIL PROTECTED] severity: normal status: open title: _sha256 module missing if openssl is not in a "normal" directory. versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2020> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4609] Allow use of > 256 FD's on solaris in 32 bit mode
New submission from Peter Saunders <[EMAIL PROTECTED]>: Feature Request: Could configure etc be modified to detect if it can use enable_extended_FILE_stdio() to allow solaris to use > 256 FD's while still be compiled 32 bit. This is a new feature in Solaris 10 (came in Update 4). Some futher infomation on this: http://developers.sun.com/solaris/articles/stdio_256.html (Scroll to "Programming Solutions") http://docs.sun.com/app/docs/doc/819-2243/enable-extended-file-stdio-3c?a=view -- components: Interpreter Core messages: 77410 nosy: [EMAIL PROTECTED] severity: normal status: open title: Allow use of > 256 FD's on solaris in 32 bit mode versions: Python 2.5, Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4609] Allow use of > 256 FD's on solaris in 32 bit mode
Changes by Peter Saunders <[EMAIL PROTECTED]>: -- components: +Distutils -Interpreter Core type: -> feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4609] Allow use of > 256 FD's on solaris in 32 bit mode
Changes by Peter Saunders <[EMAIL PROTECTED]>: -- components: +Interpreter Core -Distutils ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4609> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
New submission from Peter Saunders : I have an example code that works fine on Python 2.6.3, but when run in Python 3.1.1 - after a very short period of time, will go wrong. Summary: We have a queue, and when the queue has something in it (a list), we start a thread to deal with that entry. The thread then runs a Process for every entry in the list we popped off the queue. The Process target takes a Pipe, and it sends "True" back down the pipe, and then exits. However, this Process never goes defunct, and thus the Thread that started the Process never reaps it. When doing a truss on the Process, it sits there in: lwp_park(0x, 0) (sleeping...) -- files: testing.py messages: 93978 nosy: p...@fodder.org.uk severity: normal status: open title: Multiprocess Process does not always exit when run from a thread. versions: Python 3.1 Added file: http://bugs.python.org/file15124/testing.py ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: Further information: it doesn't fail everytime in Python 3.1 - usually 1 in 4, or 1 in 5 times. It never fails with Python 2.6.3 Example output from the script when its failing (python 3.1): Starting data1 Starting data2 Started subproc: PID: 20209 : args: data1 poll Started subproc: PID: 20210 : args: data2 poll Child has sent:True poll Child has sent:True poll isalive: False isalive: True Reaping PID: 20210 isalive: True poll Finishing: data2 isalive: True poll isalive: True poll isalive: True poll isalive: True poll : isalive: True poll isalive: True terminating Child had to be killed due to a timeout Finishing: data1 True Working output (consistantly works on Python 2.6.3): Starting data1 Starting data2 Started subproc: PID: 20252 : args: data1 poll Started subproc: PID: 20253 : args: data2 poll Child has sent:True Child has sent:True poll Child has sent:True poll isalive: False isalive: False isalive: False Reaping PID: 20252 Reaping PID: 20253 Finishing: data1 Finishing: data2 True -- ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: Well, if it helps, here is the output of the dtrace script from starting of a loop with the failure, and stopping during the failure. -- Added file: http://bugs.python.org/file15126/dtrace.txt ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: If you mean, in main() instead of doing: while True: q.put(["data1", "data2"]) t = Process(target=popJobs, args=(q, )) t.start() t.join() and doing: while True: q.put(["data1", "data2"]) popJobs(q) instead. Then, the bug does indeed occur the same way. It did take more iterations before it occured however. If however, you meant: while True: fail=failureObject() for x in ["data1", "data2"]: checkAlive(fail, x) print(fail.status()) Then the bug never occurs. -- ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: Same thing occurs, as you would expect, when I do: while True: fail=failureObject() tlist = [] for x in ["data1", "data2"]: t = threading.Thread(target=checkAlive, args = (fail, x), name=x) t.start() tlist.append(t) for x in tlist: t.join() -- ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: Further oddness: When running the script (i've reduced its size further now, see attached): I get the following output: Reaping PID: 23215 True Started subproc: PID: 23216 : args: data1 Started subproc: PID: 23216 : args: data1 Started subproc: PID: 23217 : args: data2 poll isalive: True isalive: True poll Notice the Started subprod of the SAME PID and the Same args twice, yet this print only occurs once in the code, and I can't see how this should happen? -- Added file: http://bugs.python.org/file15127/testing.py ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment:
Sorry for the spam on the updates :) - but, its the same thread printing
this out too. I changed the print line to:
curThread = threading.current_thread()
print("Started subproc: PID: %d : args: %s Thread ID: %s" %(newJob.pid,
str(args), str(curThread.ident)))
and got the output:
Reaping PID: 23707
True
Started subproc: PID: 23709 : args: data1 Thread ID: 12
Started subproc: PID: 23709 : args: data1 Thread ID: 12
poll
isalive: True
Started subproc: PID: 23710 : args: data2 Thread ID: 13
poll
isalive: True
Again, I can't see how this could pring it out twice? Could this be
related to the problem we are having? Altgough I do seem to get the line
twice on 2.6.3 as well - but nothing like as often..
--
___
Python tracker
<http://bugs.python.org/issue7123>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7123] Multiprocess Process does not always exit when run from a thread.
Peter Saunders added the comment: Tested on Linux, and repeated the issue - just to confirm this isn't a Solaris specific issue. Tested using dummy_threading - bug does not appear when that is used. Added _verbose=True to threads, and log_to_stderr(SUBDEBUG) set for Process. Attached is the output of the script with those set. Other odd things to notice, and some point, more than 2 children sometimes exist.. isalive PID: 7646 : True isalive PID: 7652 : True isalive PID: 7653 : True isalive PID: 7646 : True isalive PID: 7652 : True isalive PID: 7653 : True isalive PID: 7646 : True isalive PID: 7653 : True The code starts 2 threads, which start 2 processes. Both threads are joined before new ones are started.. So, in theroy, only 2 should be able to exist at once.. ? -- Added file: http://bugs.python.org/file15132/results1.txt ___ Python tracker <http://bugs.python.org/issue7123> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
New submission from Peter Saunders : Only sucessfully replicated on solaris. When running getpass() - it goes into non echo mode, however, once enter is pressed, the password is echoed to the screen. E.g. > /opt/python/2.6.3/bin/python -c 'import getpass; x=getpass.getpass()' Password: bob This does NOT happen on older versions: > /opt/IBpython/2.5.1/bin/python -c 'import getpass; x=getpass.getpass()' Password: /opt/python/2.3.3/bin/python -c 'import getpass; x=getpass.getpass()' Password: To stop this occuring for me, simply adding a stream.flush() line straight after the finally: termios.tcsetattr(fd, termios.TCSADRAIN, old) line fixes the issue: saun...@ln8u3494inx:[/tmp]> /opt/IBpython/2.6.3/bin/python -c 'import gp; gp.getpass()' Password: -- components: Library (Lib) messages: 94488 nosy: p...@fodder.org.uk severity: normal status: open title: Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1 versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7208] Getpass echo's password to screen on 2.6, but not on 2.5 or 3.1
Changes by Peter Saunders : -- keywords: +patch Added file: http://bugs.python.org/file15201/getpass.diff ___ Python tracker <http://bugs.python.org/issue7208> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
