[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by jacek_poplawski
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 09:01

Message:
Logged In: YES 
user_id=264913

Only version of Python from Cygwin which doesn't lock:

Python 2.4 (#1, Dec  4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more
information.
>>>

Example of version which locks (compiled by hand):
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin

Or Python 2.4.1 from current Cygwin.

Official versions of Python for Windows also don't lock,
because they use different way to implement
subprocess.Popen, but I can't use such Python - it lacks
some features of Cygwin.

PS. I don't know how to report version of Cygwin, it was
installed just by running setup.exe and downloading packages.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 22:22

Message:
Logged In: YES 
user_id=33168

Jacek, are all the failures on cygwin?  Can you report the
version of cygwin on the failing boxes as well as the
version of cygwin on the box that passed the test?

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-09-30 10:07

Message:
Logged In: YES 
user_id=264913

Yes, I can run test_subprocess.py and all 38 tests are OK
(in 15 seconds).
Just like I wrote I can't reproduce that with any simple
command, so maybe problem is that subprocess.Popen locks
_if_ application does something specific - but what?

PS. But I can reproduce that on few different computers with
different Python installations so it is not just
installation problem.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 07:33

Message:
Logged In: YES 
user_id=33168

Jason, any comments?  Is this cygwin specific or a general
subprocess issue?

--

Comment By: Peter Åstrand (astrand)
Date: 2005-09-29 21:32

Message:
Logged In: YES 
user_id=344921

Does the testsuite test_subprocess.py work correctly on this
platform?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311579 ] 2.4.2 make problems

[SourceForge.net]

Bugs item #1311579, was opened at 2005-10-03 07:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Mothersdill (nlhas)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.4.2 make problems

Initial Comment:
Recommended to post this as a bug in comp.lang.
python:


 Reply from Reinhold Birkenfeld

> I have a standard Debian x86 system with Python 2.4.1 
(compiled from
> source). Attempts to compile 2.4.2 fail with references 
to Unicode --
> is there a basic system library that's missing?
> 


Can you post a bug report to SourceForge and include 
the full output from
make there?

Also, have there been any unusual configure warnings?

Reinhold

+

No: nothing unusual that I can see in configure output -- I 
can post config.log if necessary.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311579&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1063937 ] Random core dumps

[SourceForge.net]

Bugs item #1063937, was opened at 2004-11-10 17:50
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1063937&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: munder12 (munder12)
Assigned to: Nobody/Anonymous (nobody)
Summary: Random core dumps

Initial Comment:
I have narrowed it down as far as I can by continuing
to make the problem simpler and simpler but where it
still core dumps.

The way this is set up is the following:

pytest2.py and pytest.py are in the same directory.

pytest3.py is in PYTHONPATH where PYTHONPATH is
/BASE:/SUP  (pytest3.py is in BASE).


Run ./pytest2.py several times.
This current problem core dumps on average about 2
times every 5 runs.

I have attached a file that has the Python listings as
well as the gdb traceback.

This is running under Fedora Core 1 with:

Python 2.2.3 (#1, Oct 15 2003, 23:33:35)
[GCC 3.3.1 20030930 (Red Hat Linux 3.3.1-6)] on linux2

Thank you,
Mark

PS  Strangely enough the comments in pytest.py seem to
actually increase the frequency of core dumps.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-03 11:15

Message:
Logged In: YES 
user_id=1188172

I'd say that it can be closed. As mwh says: "If Python 2.4b2
cored 25% of the time it was launched, someone else would
have noticed by now :)"

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 08:42

Message:
Logged In: YES 
user_id=33168

I can't reproduce on current CVS (2.5).  Can anyone
reproduce this now?  Should this be closed?

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-23 10:15

Message:
Logged In: YES 
user_id=1038590

I'm not sure it's relevant, but I once had a similar problem
with Python flakiness that turned out to be due to some old
.pyc files lying around (this was Fedora Core 3-test 1, and
the offending files were in my Python CVS build directory).

For whatever reason, Python wasn't picking up the version
mismatch and was trying to use the old .pyc files. Seg
faults abounded as a result.

One thought: could root ownership of pre-generated .pyc's
have that effect? (I don't know how Python reacts if it
can't delete the .pyc's)

--

Comment By: munder12 (munder12)
Date: 2004-11-17 18:00

Message:
Logged In: YES 
user_id=1156202

I have written a program in C that just opens and closes a
file repeatedly.  It appears to work fine.  But, there
appears to be much more that Python is doing behind the
scenes than what my script is explicitly directing (open and
close the file).  Since I'm not sure what all OS related
calls Python is making when opening, say, "site.py," I'm not
quite sure how I can write a C code that mimics what Python
is doing.

It may well be that the OS is the culprit.  However, it also
could be that, in the Python code itself, some error
checking is not being performed on all OS calls as they
should be since they so rarely fail on a mjority of OS's. 
Or, extra try...catch blocks maybe could be added to retry
the OS call(s) that is "incorrectly" failing on Fedora Core
1 so that Python maintains its portability with (hopefully)
minimal speed impact.

--

Comment By: Tim Peters (tim_one)
Date: 2004-11-17 01:54

Message:
Logged In: YES 
user_id=31435

At this point, it would be prudent to write the same kind of 
program in straight C, and test that.  The more you find out, 
the less it appears that Python has something to do with 
what you're seeing.  Note that it's not unusual to discover 
OS, compiler, and platform C library bugs by running Python 
programs, simply because Python builds on all of them.

--

Comment By: munder12 (munder12)
Date: 2004-11-17 01:47

Message:
Logged In: YES 
user_id=1156202

It is 2 times out of 8 runs of the main script.  Actually, that is 
2 cores out of 1600 runs of the script that really cores.  It 
does seem to be localized to Fedora Core 1.  Fedora Core 2, 
Win 2000, Win XP, and Mandrake 9 on similar hardware do not 
have the problem with these scripts.

The Python 2.4b2 is straight out of the tarball (compiled and 
installed cleanly).  The core dumps occur randomly with 
posixpath.py, site.py, etc. and at different stages (robject() 
and within fstat() (from /usr/include/sys/stat.h)).


--

Comment By: Michael

[ python-Bugs-1311674 ] broken link in sets page

[SourceForge.net]

Bugs item #1311674, was opened at 2005-10-03 07:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fernando Canizo (conaneb)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken link in sets page

Initial Comment:
In page
http://docs.python.org/lib/types-set.html
at the end says:
"See Also:
Module sets:
Differences between the sets module and the
built-in set types."

where the word "sets" is a link to:
http://docs.python.org/lib/module-comparison-to-builtin-set.html
wich gives 404 not found. Looking with google i found
the document in this other place:
http://www.python.org/dev/doc/devel/lib/comparison-to-builtin-set.html

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311674 ] broken link in sets page

[SourceForge.net]

Bugs item #1311674, was opened at 2005-10-03 12:00
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fernando Canizo (conaneb)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: broken link in sets page

Initial Comment:
In page
http://docs.python.org/lib/types-set.html
at the end says:
"See Also:
Module sets:
Differences between the sets module and the
built-in set types."

where the word "sets" is a link to:
http://docs.python.org/lib/module-comparison-to-builtin-set.html
wich gives 404 not found. Looking with google i found
the document in this other place:
http://www.python.org/dev/doc/devel/lib/comparison-to-builtin-set.html

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-03 12:32

Message:
Logged In: YES 
user_id=1188172

As far as I can see, there is no possibility to directly
link to this specific subchapter. Fred?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-971213 ] another threads+readline+signals nasty

[SourceForge.net]

Bugs item #971213, was opened at 2004-06-11 16:30
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: another threads+readline+signals nasty

Initial Comment:
python -c "import time, readline, thread;
thread.start_new_thread(raw_input, ()); time.sleep(2)"

Segfaults on ^C

Fails on Linux, freebsd.

On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3)

(gdb) where
#0  0x002627a2 in _dl_sysinfo_int80 () from
/lib/ld-linux.so.2
#1  0x008172b1 in ___newselect_nocancel () from
/lib/tls/libc.so.6
#2  0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac)
at Modules/timemodule.c:815

on FreeBSD 5.2.1-RC, a different error.

Fatal error 'longjmp()ing between thread contexts is
undefined by POSIX 1003.1' at line 72 in file
/usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2)
Abort (core dumped)


--

>Comment By: Michael Hudson (mwh)
Date: 2005-10-03 12:13

Message:
Logged In: YES 
user_id=6656

I can't, on OS X or debian.  

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 05:12

Message:
Logged In: YES 
user_id=33168

I can reproduce with cvs head (gentoo linux/amd64).

--

Comment By: Michael Hudson (mwh)
Date: 2005-04-07 10:03

Message:
Logged In: YES 
user_id=6656

I think this is fixed now, as in I can't reproduce it with CVS 
HEAD. Not sure why!  I can think of a few fixes that might be responsible.

It still messes the terminal up, though.

--

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 22:41

Message:
Logged In: YES 
user_id=6656

Bah, this still segfaults with CVS head.

--

Comment By: Michael Hudson (mwh)
Date: 2004-06-21 11:45

Message:
Logged In: YES 
user_id=6656

Can you try the patch that's *now* in 960406?  It seems to help 
for me (but I really would rather not think too hard about this!).

--

Comment By: Michal Pasternak (mpasternak)
Date: 2004-06-11 16:43

Message:
Logged In: YES 
user_id=799039

readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, 
ncurses, libc were standard from 5.2.1.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 16:39

Message:
Logged In: YES 
user_id=29957

The patch in #960406 doesn't help here.

The FC test system also has readline-4.3, if it helps, as
does the FreeBSD box. It apparently doesn't crash on OSX.



--

Comment By: Michael Hudson (mwh)
Date: 2004-06-11 16:38

Message:
Logged In: YES 
user_id=6656

Hmm.  Doesn't crash on OS X.  Messes the terminal up good and 
proper, though.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 02:05
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 03:51

Message:
Logged In: YES 
user_id=86216

Jacek,

You can use uname -a to display the Cygwin version.

Is your application.exe a Cygwin application?

AFAICT, this is probably a Cygwin bug.  Please try the
following:

1. Try the latest Cygwin snapshot to see if the problem has
already been fixed. You can download snapshots from:

http://cygwin.com/snapshots/

and replace your cygwin1.dll with this DLL.

2. Try to create a simple test case that does not involve
Python. For example, create a C program to use execvp()
to invoke your program to similuate subprocess.Popen()
with shell=False. If successful, then you've isolated the
problem to Cygwin.

3. Try to strace the problem:

$ strace -o python.log python2.4.exe -c 'import subprocess; 
subprocess.Popen("./application.exe")'

Search through python.log to look for error messages from
Cygwin.

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-02 23:01

Message:
Logged In: YES 
user_id=264913

Only version of Python from Cygwin which doesn't lock:

Python 2.4 (#1, Dec  4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more
information.
>>>

Example of version which locks (compiled by hand):
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin

Or Python 2.4.1 from current Cygwin.

Official versions of Python for Windows also don't lock,
because they use different way to implement
subprocess.Popen, but I can't use such Python - it lacks
some features of Cygwin.

PS. I don't know how to report version of Cygwin, it was
installed just by running setup.exe and downloading packages.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 12:22

Message:
Logged In: YES 
user_id=33168

Jacek, are all the failures on cygwin?  Can you report the
version of cygwin on the failing boxes as well as the
version of cygwin on the box that passed the test?

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-09-30 00:07

Message:
Logged In: YES 
user_id=264913

Yes, I can run test_subprocess.py and all 38 tests are OK
(in 15 seconds).
Just like I wrote I can't reproduce that with any simple
command, so maybe problem is that subprocess.Popen locks
_if_ application does something specific - but what?

PS. But I can reproduce that on few different computers with
different Python installations so it is not just
installation problem.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 21:33

Message:
Logged In: YES 
user_id=33168

Jason, any comments?  Is this cygwin specific or a general
subprocess issue?

--

Comment By: Peter Åstrand (astrand)
Date: 2005-09-29 11:32

Message:
Logged In: YES 
user_id=344921

Does the te

[ python-Bugs-1180147 ] test_posix fails on cygwin

[SourceForge.net]

Bugs item #1180147, was opened at 2005-04-10 03:10
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Henrik Wist (wist)
Assigned to: Jason Tishler (jlt63)
Summary: test_posix fails on cygwin

Initial Comment:
$ python test/test_posix.py
testNoArgFunctions (__main__.PosixTester) ... ERROR
test_access (__main__.PosixTester) ... ok
test_chdir (__main__.PosixTester) ... ok
test_dup (__main__.PosixTester) ... ok
test_dup2 (__main__.PosixTester) ... ok
test_fdopen (__main__.PosixTester) ... ok
test_fstat (__main__.PosixTester) ... ok
test_fstatvfs (__main__.PosixTester) ... ok
test_ftruncate (__main__.PosixTester) ... ok
test_lsdir (__main__.PosixTester) ... ok
test_pipe (__main__.PosixTester) ... ok
test_stat (__main__.PosixTester) ... ok
test_statvfs (__main__.PosixTester) ... ok
test_strerror (__main__.PosixTester) ... ok
test_tempnam (__main__.PosixTester) ... ok
test_tmpfile (__main__.PosixTester) ... ok
test_umask (__main__.PosixTester) ... ok
test_utime (__main__.PosixTester) ... ok

==
ERROR: testNoArgFunctions (__main__.PosixTester)
--
Traceback (most recent call last):
  File "test/test_posix.py", line 40, in testNoArgFunctions
posix_func()
OSError: [Errno 22] Invalid argument

--
Ran 18 tests in 0.038s

FAILED (errors=1)
Traceback (most recent call last):
  File "test/test_posix.py", line 159, in ?
test_main()
  File "test/test_posix.py", line 156, in test_main
test_support.run_unittest(PosixTester)
  File "/usr/lib/python2.3/test/test_support.py", line
262, in run_unittest
run_suite(suite, testclass)
  File "/usr/lib/python2.3/test/test_support.py", line
247, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "test/test_posix.py", line 40, in testNoArgFunctions
posix_func()
OSError: [Errno 22] Invalid argument


This is with cygwin 1.5.12-1 and python 2.3.4-2.

--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:08

Message:
Logged In: YES 
user_id=86216

AFAICT, this works correctly under Cygwin 1.5.18 and
Python 2.4.1:

$ python /usr/lib/python2.4/test/test_posix.py
testNoArgFunctions (__main__.PosixTester) ... ok
...
OK

Henrik's comment about /etc/group sounds like his Cygwin
installation was not set up correctly.

I'm closing this bug report. Please reopen if you think this is
still a problem.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 21:34

Message:
Logged In: YES 
user_id=33168

Jason, any comments?

--

Comment By: Henrik Wist (wist)
Date: 2005-04-14 01:56

Message:
Logged In: YES 
user_id=1256464

Strangely enough, this works when deleting /etc/group or 
creating it with either local groups (mkgroup -l) or domain 
groups (mkgroup -d). I guess it is more a cygwin problem, 
then.

--

Comment By: Henrik Wist (wist)
Date: 2005-04-10 03:12

Message:
Logged In: YES 
user_id=1256464

And, I forgot, this is with WinXP SP2

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1180147&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1179412 ] can't import thru cygwin symlink

[SourceForge.net]

Bugs item #1179412, was opened at 2005-04-08 11:42
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: steveward (steveward)
Assigned to: Jason Tishler (jlt63)
Summary: can't import thru cygwin symlink

Initial Comment:
This may be a cygwin-specific problem: given foo.py:

> ln -s foo.py bar.py
> python
Python 2.4 (#1, Dec  4 2004, 20:10:33)
[GCC 3.3.3 (cygwin special)] on cygwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import foo
This is file foo.py.
>>> import bar
Traceback (most recent call last):
  File "", line 1, in ?
ImportError: No module named bar

Despite the problem with imports,  most os.path utilities 
(exists, isfile, islink, isdir) work on cygwin symlinks.   
An exception is reailpath: realpath("bar.py") returns a 
path to the symlink, not to the real file.

Suspecting this as a key to the import problem, I tried 
several recent python/cygwin release versions (all 
installed via cygwin's setup.exe).  
FIndings: 

 Cygwin   Python   realpath  Import
  1.5.xx:  2.yy:   Works?  Works?
  -  --  ---  --
 1.5.14 2.4NO  NO
 1.5.13   2.3.4 YES  NO
 1.5.14   2.3.4 YES  NO
 1.5.12 2.4NOYES

Neither bug shows up under Linux.

The two problems seem uncorrelated, although it may 
be that each is due to some assumpion about symlink 
semantics that isn't true of the Cygwin implementation.

Apologies if these problems have been previously 
submitted in a form my quick scan didn't identify.  A 
corresponding note has been submitted to the cygwin 
mailing list.

- Steve
 

--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:16

Message:
Logged In: YES 
user_id=86216

This is a duplicate of patch #1197318.

Note Cygwin Python 2.4.1 has this patch applied.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 21:36

Message:
Logged In: YES 
user_id=33168

Jason, comments?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1179412&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes

[SourceForge.net]

Bugs item #1311784, was opened at 2005-10-03 12:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Klotz (pete_icoserve)
Assigned to: Nobody/Anonymous (nobody)
Summary: python.exe 2.4.2 compiled with VS2005 crashes

Initial Comment:
The C runtime library shipped with Visual Studio 2005
performs strict checking of parameters.

In function initsignal() in file
Modules\signalmodule.c, an iteration over all signals
from 1 to NSIG is performed.

The function PyOS_getsig() is called with each of these
integer values. PyOS_getsig() then calls signal() with
the given value which leads to the crash.

According to signal.h from VS2005 only these signals
are allowed:

#define SIGINT  2 
#define SIGILL  4 
#define SIGABRT_COMPAT  6 
#define SIGFPE  8 
#define SIGSEGV 11
#define SIGTERM 15
#define SIGBREAK21
#define SIGABRT 22

A solution would be to restrict the loop in
initsignal() to the above values under Windows.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-864374 ] 2.3.3 tests on cygwin

[SourceForge.net]

Bugs item #864374, was opened at 2003-12-22 02:30
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Jason Tishler (jlt63)
Summary: 2.3.3 tests on cygwin

Initial Comment:
Hello,

After running
./configure --prefix=/usr 
make
make test 

I get the following 
---
217 tests OK.
7 tests failed:
test_bz2 test_fork1 test_largefile test_os
test_popen2 test_pty
test_tempfile
31 tests skipped:
test_aepack test_al test_bsddb185 test_bsddb3
test_cd test_cl
test_curses test_dbm test_email_codecs test_gl
test_imgfile
test_ioctl test_linuxaudiodev test_locale test_macfs
test_macostools test_mpz test_nis test_normalization
test_ossaudiodev test_pep277 test_plistlib
test_scriptpackages
test_socket_ssl test_socketserver test_sunaudiodev
test_timeout
test_unicode_file test_urllibnet test_winreg
test_winsound
Those skips are all expected on cygwin.

When running test_bz2, test_fork1, test_popen2,
test_pty, test_tempfile alone they look ok (return
value to OS is 0).
For the others I'm attaching output.

My system is win2k on IBM T30 (laptop).
Cygwin 1.5.5. 

Miki

--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:24

Message:
Logged In: YES 
user_id=86216

AFAICT, this is due to the known Cygwin fork() rebase
problem. Although, I can't be sure because Miki did not
include the actual error messages.

If my assumption is correct, then rebasing your system
(including the DLLs from the build), should solve the problem.

I'm closing the bug report. Please reopen if you this is still
a problem.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 21:37

Message:
Logged In: YES 
user_id=33168

Jason?

--

Comment By: Miki Tebeka (tebeka)
Date: 2005-08-28 03:02

Message:
Logged In: YES 
user_id=358087

Sorry, due to some bizzar DLL relocation problems with
cygwin I can't run the rull test suite.

However test_bz2 fails *before* the test suite gets stuck

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-08-25 05:28

Message:
Logged In: YES 
user_id=1188172

Can you verify this with 2.4.1 or a CVS version?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=864374&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1101756 ] popen4/cygwin ssh hangs

[SourceForge.net]

Bugs item #1101756, was opened at 2005-01-13 07:21
Message generated for change (Settings changed) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Ph.E (ph_e)
Assigned to: Jason Tishler (jlt63)
Summary: popen4/cygwin ssh hangs

Initial Comment:
The following python code hangs on executing cmd2
(works with cmd1).
The commands works fine when executed on a shell.
I have the same problem with Python 2.3.4 and 2.4
(Windows).
I use the latest Cygwin binaries 


import os

cmd1 = "bin\ssh"
cmd2 = "bin\ssh -i id_dsa [EMAIL PROTECTED] uptime"

def docmd(cmd):
print "Doing %s ..." % cmd

(stdin, stdouterr) = os.popen4(cmd)

for line in stdouterr.readlines():
print line

stdin.close()
stdouterr.close()
print "Done."

if __name__ == '__main__':
docmd(cmd1)
docmd(cmd2)

Give me some advice for testing (popen, linux, ...).


--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:36

Message:
Logged In: YES 
user_id=86216

AFAICT, this works for me under Cygwin 1.5.18 and Python
2.4.1:

$ python /tmp/sf.py
Doing ssh ...
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-
c cipher_spec]

   [-D port] [-e escape_char] [-F configfile]

   [-i identity_file] [-L [bind_address:]port:host:hostport]

   [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o 
option] [-p port]

   [-R [bind_address:]port:host:hostport] [-S ctl_path]

   [EMAIL PROTECTED] [command]

Done.
Doing ssh -i id_rsa server uptime ...
  8:29am  up 1 day(s),  1:53,  5 users,  load average: 0.41, 
0.52, 0.59

Done.

Note I changed cmd1 and cmd2 also follows:

cmd1 = "ssh"
cmd2 = "ssh -i id_rsa server uptime"

I'm closing this bug report. Please reopen if this is still
a problem.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 21:36

Message:
Logged In: YES 
user_id=33168

Jason?

--

Comment By: Ph.E (ph_e)
Date: 2005-01-13 08:33

Message:
Logged In: YES 
user_id=1196530

The same code in Linux Python 2.3.4 works fine.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1101756&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by jacek_poplawski
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error messages, I found some lines like that:

   52   16939 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   89   17028 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe) failed
   49   17077 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   87   17164 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe.lnk) failed

or: 

   49   41683 [main] python2.4 3380 geterrno_from_win_error:
windows error 3 == errno 2
   85   41768 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (C:\cygwin-new\usr\local\bin\lib\python2.4\li
b-dynload.exe) failed

they repeat many times in log

I don't see anything suspicious in the place where
application.exe is forked:

 651 1135006 [main] python2.4 3612 spawnve: spawnve
(./application.exe, ./application.exe, 460090)
(...)
   55 1137090 [main] python2.4 3612 child_info::child_info:
subproc_ready 0x6DC
test_rpc\jp_test\Builds\Demo\LBS\cygwin\RELEASE\application.exe)
   80 1141223 [main] python2.4 3612! spawn_guts: new process
name 
c:\tmp\builds\test_rpc\jp_test\Builds\Demo\LBS\cygwinRELEASE\application.exe
  227 1141450 [main] python2.4 3612! _pinfo::dup_proc_pipe:
closed wr_proc_pipe 0x7FC for pid 3612(3348)

Do you need full log?

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 13:51

Message:
Logged In: YES 
user_id=86216

Jacek,

You can use uname -a to display the Cygwin version.

Is your application.exe a Cygwin application?

AFAICT, this is probably a Cygwin bug.  Please try the
following:

1. Try the latest Cygwin snapshot to see if the problem has
already been fixed. You can download snapshots from:

http://cygwin.com/snapshots/

and replace your cygwin1.dll with this DLL.

2. Try to create a simple test case that does not involve
Python. For example, create a C program to use execvp()
to invoke your program to similuate subprocess.Popen()
with shell=False. If successful, then you've isolated the
problem to Cygwin.

3. Try to strace the problem:

$ strace -o python.log python2.4.exe -c 'import subprocess; 
subprocess.Popen("./application.exe")'

Search through python.log to look for error messages from
Cygwin.

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 09:01

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 02:05
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:47

Message:
Logged In: YES 
user_id=86216

> $ uname -a
> CYGWIN_NT-5.1 widlobrody 1.5.18

Please try the latest Cygwin snapshot.

> please notice that in the subprocess.py it locks after
> execvp

Where exactly does it lock up in subprocess.py?

If you can create a simple test case (in C), then the core
Cygwin developers are likely to try to debug the problem.

Since the problem only happens (so far) with application.exe,
I don't know how to debug the problem further. :,(

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 04:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error messages, I found some lines like that:

   52   16939 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   89   17028 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe) failed
   49   17077 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   87   17164 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe.lnk) failed

or: 

   49   41683 [main] python2.4 3380 geterrno_from_win_error:
windows error 3 == errno 2
   85   41768 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (C:\cygwin-new\usr\local\bin\lib\python2.4\li
b-dynload.exe) failed

they repeat many times in log

I don't see anything suspicious in the place where
application.exe is forked:

 651 1135006 [main] python2.4 3612 spawnve: spawnve
(./application.exe, ./application.exe, 460090)
(...)
   55 1137090 [main] python2.4 3612 child_info::child_info:
subproc_ready 0x6DC
test_rpc\jp_test\Builds\Demo\LBS\cygwin\RELEASE\application.exe)
   80 1141223 [main] python2.4 3612! spawn_guts: new process
name 
c:\tmp\builds\test_rpc\jp_test\Builds\Demo\LBS\cygwinRELEASE\application.exe
  227 1141450 [main] python2.4 3612! _pinfo::dup_proc_pipe:
closed wr_proc_pipe 0x7FC for pid 3612(3348)

Do you need full log?

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 03:51

Message:
Logged In: YES 
user_id=86216

Jacek,

You can use uname -a to display the Cygwin version.

Is your application.exe a Cygwin application?

AFAICT, this is probably a Cygwin bug.  Please try the
following:

1. Try the latest Cygwin snapshot to see if the problem has
already been fixed. You can download snapshots from:

http://cygwin.com/snapshots/

and replace your cygwin1.dll with thi

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by jacek_poplawski
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:54

Message:
Logged In: YES 
user_id=264913

Update... we tried to compile new Python version on computer
where 2.4.0 worked correctly, and... it still works. So -
like you said - problem may be related to cygwin setup,
because this one computer has older gcc and older cygwin:

Python 2.4.2 (#1, Oct  3 2005, 14:31:11)
[GCC 3.3.3 (cygwin special)] on cygwin

CYGWIN_NT-5.1 BOLESTY 1.5.13(0.122/4/2) 2005-03-01 11:01
i686 unknown unknown Cygwin

Now we are trying to update gcc on that computer to check
will it fail with never one. However, it would be nice to
have any way to fix that in subprocess.py, because I don't
even know what to report for Cygwin guys.

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 14:47

Message:
Logged In: YES 
user_id=86216

> $ uname -a
> CYGWIN_NT-5.1 widlobrody 1.5.18

Please try the latest Cygwin snapshot.

> please notice that in the subprocess.py it locks after
> execvp

Where exactly does it lock up in subprocess.py?

If you can create a simple test case (in C), then the core
Cygwin developers are likely to try to debug the problem.

Since the problem only happens (so far) with application.exe,
I don't know how to debug the problem further. :,(

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error messages, I found some lines like that:

   52   16939 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   89   17028 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe) failed
   49   17077 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   87   17164 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe.lnk) failed

or: 

   49   41683 [main] python2.4 3380 geterrno_from_win_error:
windows error 3 == errno 2
   85   41768 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (C:\cygwin-new\usr\local\bin\lib\python2.4\li
b-dynload.exe) failed

they repeat many times in log

I don't see anything suspicious in the place where
application.exe is forked:

 651 1135006 [main] python2.4 3612 spawnve: spawnve
(./application.exe, ./application.exe, 460090)
(...)
   55 1137090 [main] python2.4 3612 child_info::child_info:
subproc_ready 0x6DC
test_rpc\jp_test\Builds\Demo\LBS\cygwin\RELEASE\appl

[ python-Bugs-969492 ] Python hangs up on I/O operations on the latest FreeBSD 4.10

[SourceForge.net]

Bugs item #969492, was opened at 2004-06-09 17:03
Message generated for change (Comment added) made by iww
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969492&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: _Iww_ (iww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python hangs up on I/O operations on the latest FreeBSD 4.10

Initial Comment:
Hello, friends!
Here is my sample code, which works perfectly on other systems, but not 
the FreeBSD 4.10-STABLE I got today by cvsupping.

#!/usr/local/bin/python
from threading import Thread
class Reading(Thread):
 def __init__(self):
  Thread.__init__(self)
 def run(self):
  print "Start!"
  z = 1
  while 1:
   print z
   z += 1
   fl = open('blah.txt')
   fl.read()
   fl.close()

for i in range(10):
 print "i:", i
 zu = open('bzzz.txt')
 print "|->", zu.read()
 bzz = Reading()
 bzz.start()
#---
I have tested this on Python 2.3.3, 2.3.4 and 2.4a0 from CVS.
The interpretar falls in the infinite loop and stays in the poll-state.
You can see it in the top:
34446 goga2   0  3328K  2576K poll 0:00  0.00%  0.00% python

I think it has some connection to the latest bug, found in the select() 
function (http://www.securityfocus.com/bid/10455) and its fix on BSD.

Best regards,
_Iww_

--

>Comment By: _Iww_ (iww)
Date: 2005-10-03 19:56

Message:
Logged In: YES 
user_id=1059927

nnorwitz, thank you for your attantion!
It was really a short problem in FreeBSD sources. The last version of python did
not worked well.
The bug was solved shortly after my post.

Best regards,
_Iww_

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 11:05

Message:
Logged In: YES 
user_id=33168

iww, is this a FreeBSD bug?  Does the problem still exist?

--

Comment By: Jeff Epler (jepler)
Date: 2004-06-22 04:52

Message:
Logged In: YES 
user_id=2772

Indentation was lost on your example.  Please attach it it
to the bug report as a file instead.

In my opinion, the problem you're having is unlikely to be
related to the securityfocus URL you mentioned.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969492&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by astrand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Peter Åstrand (astrand)
Date: 2005-10-03 14:59

Message:
Logged In: YES 
user_id=344921

My guess is that you have a race-condition in application.exe. 

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:54

Message:
Logged In: YES 
user_id=264913

Update... we tried to compile new Python version on computer
where 2.4.0 worked correctly, and... it still works. So -
like you said - problem may be related to cygwin setup,
because this one computer has older gcc and older cygwin:

Python 2.4.2 (#1, Oct  3 2005, 14:31:11)
[GCC 3.3.3 (cygwin special)] on cygwin

CYGWIN_NT-5.1 BOLESTY 1.5.13(0.122/4/2) 2005-03-01 11:01
i686 unknown unknown Cygwin

Now we are trying to update gcc on that computer to check
will it fail with never one. However, it would be nice to
have any way to fix that in subprocess.py, because I don't
even know what to report for Cygwin guys.

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 14:47

Message:
Logged In: YES 
user_id=86216

> $ uname -a
> CYGWIN_NT-5.1 widlobrody 1.5.18

Please try the latest Cygwin snapshot.

> please notice that in the subprocess.py it locks after
> execvp

Where exactly does it lock up in subprocess.py?

If you can create a simple test case (in C), then the core
Cygwin developers are likely to try to debug the problem.

Since the problem only happens (so far) with application.exe,
I don't know how to debug the problem further. :,(

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error messages, I found some lines like that:

   52   16939 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   89   17028 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe) failed
   49   17077 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   87   17164 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe.lnk) failed

or: 

   49   41683 [main] python2.4 3380 geterrno_from_win_error:
windows error 3 == errno 2
   85   41768 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (C:\cygwin-new\usr\local\bin\lib\python2.4\li
b-dynload.exe) failed

they repeat many times in log

I don't see anything suspicious in the place where
application.exe is forked:

 651 11

[ python-Bugs-973103 ] empty raise after handled exception

[SourceForge.net]

Bugs item #973103, was opened at 2004-06-15 09:36
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Neal Norwitz (nnorwitz)
Summary: empty raise after handled exception

Initial Comment:
executing empty raise after handled exception produces
wrong traceback.

no exception:

Traceback (most recent call last):
  File "bug.py", line 19, in ?
test(i)
  File "bug.py", line 15, in test
badfn()
  File "bug.py", line 5, in badfn
raise
TypeError: exceptions must be classes, instances, or
strings (deprecated), not NoneType

handled exception:

no
Traceback (most recent call last):
  File "bug.py", line 19, in ?
test(i)
  File "bug.py", line 15, in test
badfn()
  File "bug.py", line 11, in test
print d[12345]
KeyError: 12345


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-03 12:59

Message:
Logged In: YES 
user_id=4771

Sorry, my mistake.  I confused the try: part and the finally: part of the 
try:finally:.  You can use 'continue' in the former but not in the latter.

I don't see off-hand a deep problem in supporting 'continue' in the finally: 
part, which probably means that I am not thinking hard enough.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 04:38

Message:
Logged In: YES 
user_id=33168

Armin, your comment about continue says that it's not
illegal inside a try/finally?  Is that exactly correct? 
continue can be used inside a try, except, else, but not
finally from my testing.  Is that correct?

I agree that the wording of 7.4 is still not correct.  The
try should be changed to a finally.  Should the laziness
comment be removed?  Should continue be allowed inside a
finally?  Does the exception get eatten like return inside a
finally?

6.9 needs some work too.  I asked Raymond about some of the
current wording which he seems to have modified last.

--

Comment By: Armin Rigo (arigo)
Date: 2004-06-24 10:06

Message:
Logged In: YES 
user_id=4771

This is the intended behavior, although the docs that explain that are not too 
clear: "raise" is equivalent to re-raising what "sys.get_info()" returns; the 
docs about sys.get_info() explain in detail why you get this behavior.

The language reference 6.9 should mention this.  (Btw the language reference 
7.4 still says that continue is illegal within try:finally:, which is no longer 
the case.)

The reason sys.get_info() has access to the exception handled in a parent frame 
is to be able to implement things like traceback.print_exc().  But I don't know 
exactly why it should be the case that an exception remains active after its 
handler finished.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes

[SourceForge.net]

Bugs item #1311784, was opened at 2005-10-03 13:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Klotz (pete_icoserve)
Assigned to: Nobody/Anonymous (nobody)
Summary: python.exe 2.4.2 compiled with VS2005 crashes

Initial Comment:
The C runtime library shipped with Visual Studio 2005
performs strict checking of parameters.

In function initsignal() in file
Modules\signalmodule.c, an iteration over all signals
from 1 to NSIG is performed.

The function PyOS_getsig() is called with each of these
integer values. PyOS_getsig() then calls signal() with
the given value which leads to the crash.

According to signal.h from VS2005 only these signals
are allowed:

#define SIGINT  2 
#define SIGILL  4 
#define SIGABRT_COMPAT  6 
#define SIGFPE  8 
#define SIGSEGV 11
#define SIGTERM 15
#define SIGBREAK21
#define SIGABRT 22

A solution would be to restrict the loop in
initsignal() to the above values under Windows.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-10-03 14:05

Message:
Logged In: YES 
user_id=6656

Is VS2005 actually out now then?  This behaviour violates the C standard, 
as far as we can tell, so we when VS2005 was in beta we hoped that they 
would fix it for the final release.

If it is released, though, I guess we need to do something like you suggest 
(along with some colourful comments, I guess).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 12:05
Message generated for change (Comment added) made by jacek_poplawski
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 15:11

Message:
Logged In: YES 
user_id=264913

Problem has been fixed after update of cygwin1.dll, THANKS A
LOT!

PS. could you explain "race-condition"?
PS2. Is it development version of cygwin? Why isn't
available thru setup.exe?
CYGWIN_NT-5.1 widlobrody 1.5.19s(0.138/4/2) 20050930
20:02:20 i686 unknown unknown Cygwin


--

Comment By: Peter Åstrand (astrand)
Date: 2005-10-03 14:59

Message:
Logged In: YES 
user_id=344921

My guess is that you have a race-condition in application.exe. 

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:54

Message:
Logged In: YES 
user_id=264913

Update... we tried to compile new Python version on computer
where 2.4.0 worked correctly, and... it still works. So -
like you said - problem may be related to cygwin setup,
because this one computer has older gcc and older cygwin:

Python 2.4.2 (#1, Oct  3 2005, 14:31:11)
[GCC 3.3.3 (cygwin special)] on cygwin

CYGWIN_NT-5.1 BOLESTY 1.5.13(0.122/4/2) 2005-03-01 11:01
i686 unknown unknown Cygwin

Now we are trying to update gcc on that computer to check
will it fail with never one. However, it would be nice to
have any way to fix that in subprocess.py, because I don't
even know what to report for Cygwin guys.

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 14:47

Message:
Logged In: YES 
user_id=86216

> $ uname -a
> CYGWIN_NT-5.1 widlobrody 1.5.18

Please try the latest Cygwin snapshot.

> please notice that in the subprocess.py it locks after
> execvp

Where exactly does it lock up in subprocess.py?

If you can create a simple test case (in C), then the core
Cygwin developers are likely to try to debug the problem.

Since the problem only happens (so far) with application.exe,
I don't know how to debug the problem further. :,(

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 14:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error messages, I found some lines like that:

   52   16939 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   89   17028 [main] python2.4 3380 symlink_info::check:
GetFileAttributes (c:\tmp\builds\test
BS\cygwin\RELEASE\import subprocess;
subprocess.Popen(".\application.exe").exe) failed
   49   17077 [main] python2.4 3380 geterrno_from_win_error:
windows error 123 == errno 2
   87   17164 [main] python2.4 3380 symlink_info::check:
GetFileAttributes

[ python-Bugs-969492 ] Python hangs up on I/O operations on the latest FreeBSD 4.10

[SourceForge.net]

Bugs item #969492, was opened at 2004-06-09 12:03
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969492&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: _Iww_ (iww)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python hangs up on I/O operations on the latest FreeBSD 4.10

Initial Comment:
Hello, friends!
Here is my sample code, which works perfectly on other systems, but not 
the FreeBSD 4.10-STABLE I got today by cvsupping.

#!/usr/local/bin/python
from threading import Thread
class Reading(Thread):
 def __init__(self):
  Thread.__init__(self)
 def run(self):
  print "Start!"
  z = 1
  while 1:
   print z
   z += 1
   fl = open('blah.txt')
   fl.read()
   fl.close()

for i in range(10):
 print "i:", i
 zu = open('bzzz.txt')
 print "|->", zu.read()
 bzz = Reading()
 bzz.start()
#---
I have tested this on Python 2.3.3, 2.3.4 and 2.4a0 from CVS.
The interpretar falls in the infinite loop and stays in the poll-state.
You can see it in the top:
34446 goga2   0  3328K  2576K poll 0:00  0.00%  0.00% python

I think it has some connection to the latest bug, found in the select() 
function (http://www.securityfocus.com/bid/10455) and its fix on BSD.

Best regards,
_Iww_

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-03 15:36

Message:
Logged In: YES 
user_id=1188172

Closing then.

--

Comment By: _Iww_ (iww)
Date: 2005-10-03 14:56

Message:
Logged In: YES 
user_id=1059927

nnorwitz, thank you for your attantion!
It was really a short problem in FreeBSD sources. The last version of python did
not worked well.
The bug was solved shortly after my post.

Best regards,
_Iww_

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 06:05

Message:
Logged In: YES 
user_id=33168

iww, is this a FreeBSD bug?  Does the problem still exist?

--

Comment By: Jeff Epler (jepler)
Date: 2004-06-21 23:52

Message:
Logged In: YES 
user_id=2772

Indentation was lost on your example.  Please attach it it
to the bug report as a file instead.

In my opinion, the problem you're having is unlikely to be
related to the securityfocus URL you mentioned.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=969492&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307798 ] subprocess.Popen locks on Cygwin

[SourceForge.net]

Bugs item #1307798, was opened at 2005-09-29 02:05
Message generated for change (Comment added) made by jlt63
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307798&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jacek Poplawski (jacek_poplawski)
Assigned to: Jason Tishler (jlt63)
Summary: subprocess.Popen locks on Cygwin

Initial Comment:
I have problem running application with
subprocess.Popen, it happens only on Python from Cygwin
or compiled on Cygwin. It works correctly on Linux,
QNX, and Python from Windows installer, it also works
on one version of Python 2.4.0 from Cygwin.

When I run application with shell=True - everything is
OK, but when I run it without it - Popen locks on data
= os.read(errpipe_read, 1048576). 

Using options stdin, stdout, stderr doesn't help.

I can't reproduce it with any simple application,
application I am running is written in C++, multithreaded. 

$ python
Python 2.4.2 (#1, Sep 29 2005, 10:56:12)
[GCC 3.4.4 (cygming special) (gdc 0.12, using dmd
0.125)] on cygwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> import subprocess
>>> subprocess.Popen("./application.exe")
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/local/lib/python2.4/subprocess.py", line
542, in __init__
errread, errwrite)
  File "/usr/local/lib/python2.4/subprocess.py", line
970, in _execute_child
data = os.read(errpipe_read, 1048576) # Exceptions
limited to 1 MB
KeyboardInterrupt
>>> subprocess.Popen("./application.exe",shell=True)



--

>Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 05:43

Message:
Logged In: YES 
user_id=86216

> Problem has been fixed after update of cygwin1.dll

Good!

> THANKS A LOT!

You are quite welcome.

> Is it development version of cygwin?

Yes.

> Why isn't available thru setup.exe?

Because it is not a release -- it's just a snapshot of CVS.
It will be available through setup.exe when 1.5.19 is released.




--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 05:11

Message:
Logged In: YES 
user_id=264913

Problem has been fixed after update of cygwin1.dll, THANKS A
LOT!

PS. could you explain "race-condition"?
PS2. Is it development version of cygwin? Why isn't
available thru setup.exe?
CYGWIN_NT-5.1 widlobrody 1.5.19s(0.138/4/2) 20050930
20:02:20 i686 unknown unknown Cygwin


--

Comment By: Peter Åstrand (astrand)
Date: 2005-10-03 04:59

Message:
Logged In: YES 
user_id=344921

My guess is that you have a race-condition in application.exe. 

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 04:54

Message:
Logged In: YES 
user_id=264913

Update... we tried to compile new Python version on computer
where 2.4.0 worked correctly, and... it still works. So -
like you said - problem may be related to cygwin setup,
because this one computer has older gcc and older cygwin:

Python 2.4.2 (#1, Oct  3 2005, 14:31:11)
[GCC 3.3.3 (cygwin special)] on cygwin

CYGWIN_NT-5.1 BOLESTY 1.5.13(0.122/4/2) 2005-03-01 11:01
i686 unknown unknown Cygwin

Now we are trying to update gcc on that computer to check
will it fail with never one. However, it would be nice to
have any way to fix that in subprocess.py, because I don't
even know what to report for Cygwin guys.

--

Comment By: Jason Tishler (jlt63)
Date: 2005-10-03 04:47

Message:
Logged In: YES 
user_id=86216

> $ uname -a
> CYGWIN_NT-5.1 widlobrody 1.5.18

Please try the latest Cygwin snapshot.

> please notice that in the subprocess.py it locks after
> execvp

Where exactly does it lock up in subprocess.py?

If you can create a simple test case (in C), then the core
Cygwin developers are likely to try to debug the problem.

Since the problem only happens (so far) with application.exe,
I don't know how to debug the problem further. :,(

--

Comment By: Jacek Poplawski (jacek_poplawski)
Date: 2005-10-03 04:37

Message:
Logged In: YES 
user_id=264913

$ uname -a
CYGWIN_NT-5.1 widlobrody 1.5.18(0.132/4/2) 2005-07-02 20:30
i686 unknown unknown Cygwin

Our application compiles with cygwin gcc and Microsoft
Visual Studio, problem happens on both versions.

execvp with this application works in Python, problem is
only with subprocess.Popen, please notice that in the
subprocess.py it locks after execvp

in log (after I break application with ctrl+c) I can't find
any cygwin error

[ python-Bugs-979739 ] compile of code with incorrect encoding yields MemoryError

[SourceForge.net]

Bugs item #979739, was opened at 2004-06-25 07:45
Message generated for change (Comment added) made by atuining
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979739&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.3
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Anthony Tuininga (atuining)
Assigned to: Neal Norwitz (nnorwitz)
Summary: compile of code with incorrect encoding yields MemoryError

Initial Comment:
The following code will fail in both Python 2.3 and
Python 2.4, raising a MemoryError exception, when run
on any platform except Windows:

compile("# -*- coding: mbcs -*-", "test.py", "exec")

This has been reproduced on the following platforms:

Linux x86
HP-UX
Solaris
Tru64 Unix

I realize this is an invalid encoding but it would be
nice if something other than MemoryError was raised!

--

>Comment By: Anthony Tuininga (atuining)
Date: 2005-10-03 08:03

Message:
Logged In: YES 
user_id=619560

No need to backport -- the solution is quite simple. I was
simply reporting it so that it would eventually get fixed.
And it has, so I'm happy. :-)

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 23:00

Message:
Logged In: YES 
user_id=33168

Duplicate of #772896.  This has been fixed in CVS.  It's up
to Anthony whether it should be backported to 2.4 or not.

--

Comment By: Michael Hudson (mwh)
Date: 2004-08-07 15:33

Message:
Logged In: YES 
user_id=6656

Here's a simple and seemingly effective patch.  I'm not sure
it's "the right thing", though.  The whole issue of whether
the parser should or should not set exceptions is a
frightful mess.

--

Comment By: Thomas Heller (theller)
Date: 2004-06-25 13:09

Message:
Logged In: YES 
user_id=11105

I assume the behaviour occurrs when an unknown encoding is
specified.  It can be reproduced on Windows:

compile("# -*- coding: xxx -*-", "test.py", "exec")

It should probably raise a SyntaxError, as trying to import
a module containing this encoding does.

The problem seems that when
PyParser_ParseStringFlagsFilename() calls
PyTokenizer_FromString(), and when the latter fails the
error is set to E_NOMEM.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=979739&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311674 ] broken link in sets page

[SourceForge.net]

Bugs item #1311674, was opened at 2005-10-03 06:00
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fernando Canizo (conaneb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: broken link in sets page

Initial Comment:
In page
http://docs.python.org/lib/types-set.html
at the end says:
"See Also:
Module sets:
Differences between the sets module and the
built-in set types."

where the word "sets" is a link to:
http://docs.python.org/lib/module-comparison-to-builtin-set.html
wich gives 404 not found. Looking with google i found
the document in this other place:
http://www.python.org/dev/doc/devel/lib/comparison-to-builtin-set.html

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-10-03 10:27

Message:
Logged In: YES 
user_id=3066

Fixed in the sources; Doc/lib/libstdtypes.tex revisions
1.186 and 1.170.2.14.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-03 06:32

Message:
Logged In: YES 
user_id=1188172

As far as I can see, there is no possibility to directly
link to this specific subchapter. Fred?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311674&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-994100 ] seg fault when calling bsddb.hashopen()

[SourceForge.net]

Bugs item #994100, was opened at 2004-07-19 16:21
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994100&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: seg fault when calling bsddb.hashopen()

Initial Comment:
Fresh 2.3.4 build (didn't even install!) on Mandrake
8.1-ish system
using Berkeley DB 3.3 yields this output when trying to
create a new hash db:

Python 2.3.4 (#1, Jul 19 2004, 16:02:09) 
[GCC 3.0.1] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import bsddb
>>> bsddb.__file__
'/home/skip/src/Python-2.3.4/Lib/bsddb/__init__.pyc'
>>> bsddb.hashopen("foo.db", "c")

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 22763)]
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x404e284b in newDBObject (arg=0x0, flags=0)
at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:697
#2  0x404ee808 in DB_construct (self=0x0,
args=0x401a602c, kwargs=0x0)
at /home/skip/src/Python-2.3.4/Modules/_bsddb.c:4322
#3  0x080f718a in PyCFunction_Call (func=0x4047344c,
arg=0x401a602c, kw=0x0)
at Objects/methodobject.c:93
#4  0x080b122d in call_function (pp_stack=0xb31c,
oparg=0)
at Python/ceval.c:3439
#5  0x080af680 in eval_frame (f=0x8195a0c) at
Python/ceval.c:2116
#6  0x080b0382 in PyEval_EvalCodeEx (co=0x4047ff60,
globals=0x404859bc, 
locals=0x0, args=0x818e13c, argcount=2,
kws=0x818e144, kwcount=0, 
defs=0x404868f8, defcount=8, closure=0x0) at
Python/ceval.c:2663
#7  0x080b2ea1 in fast_function (func=0x40486454,
pp_stack=0xb4bc, n=2, 
na=2, nk=0) at Python/ceval.c:3529
#8  0x080b1119 in call_function (pp_stack=0xb4bc,
oparg=2)
at Python/ceval.c:3458
#9  0x080af680 in eval_frame (f=0x818dfec) at
Python/ceval.c:2116
#10 0x080b0382 in PyEval_EvalCodeEx (co=0x4046a920,
globals=0x401bd79c, 
locals=0x401bd79c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
defcount=0, closure=0x0) at Python/ceval.c:2663
#11 0x080b2dd5 in PyEval_EvalCode (co=0x4046a920,
globals=0x401bd79c, 
locals=0x401bd79c) at Python/ceval.c:537
#12 0x080d34ab in run_node (n=0x401a6a88,
filename=0x80f9fe8 "", 
globals=0x401bd79c, locals=0x401bd79c,
flags=0xb6cc)
at Python/pythonrun.c:1267
#13 0x080d185c in PyRun_InteractiveOneFlags
(fp=0x4019cf60, 
filename=0x80f9fe8 "", flags=0xb6cc) at
Python/pythonrun.c:757
#14 0x080d164e in PyRun_InteractiveLoopFlags
(fp=0x4019cf60, 
filename=0x80f9fe8 "", flags=0xb6cc) at
Python/pythonrun.c:690
#15 0x080d2c08 in PyRun_AnyFileExFlags (fp=0x4019cf60, 
filename=0x80f9fe8 "", closeit=0,
flags=0xb6cc)
at Python/pythonrun.c:653
#16 0x0805508c in Py_Main (argc=1, argv=0xb7a4) at
Modules/main.c:415
#17 0x08054a99 in main (argc=1, argv=0xb7a4) at
Modules/python.c:23
#18 0x400825b0 in __libc_start_main () from /lib/libc.so.6

ldd tells me this is how it's linked:

% ldd build/lib.linux-i686-2.3/_bsddb.so 
libdb-3.3.so => /lib/libdb-3.3.so (0x40022000)
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x400b2000)
libc.so.6 => /lib/libc.so.6 (0x400ba000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

What's the oldest Berkeley DB usable with the
bsddb package?  According to the README file
versions 3.1 through 4.1 are supported.  According
to Modules/_bsddb.c versions 3.2 through 4.2 are
supported.  According to comments in setup.py 3.1
is only partially supported.  I'm wondering if maybe
the bar
has been raised even higher and 3.3 is no longer supported.

Skip


--

>Comment By: Skip Montanaro (montanaro)
Date: 2005-10-03 09:46

Message:
Logged In: YES 
user_id=44345

It's been ages.  I'll assume Greg just didn't close it...


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 00:19

Message:
Logged In: YES 
user_id=33168

Skip, is this still a problem?

--

Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 06:17

Message:
Logged In: YES 
user_id=413

I just committed a rewrite of the bsddb library+include file finding portion of 
python's setup.py.  Could you try python CVS head on the system you had this 
problem on?  It should now pick a properly paired header file and library 
version.

--

Comment By: Skip Montanaro (montanaro)
Date: 2004-07-19 21:22

Message:
Logged In: YES 
user_id=44345

I rebuilt it with 3.3, but noticed

[ python-Bugs-1311993 ] Python breakdown in windows (uses apsw)

[SourceForge.net]

Bugs item #1311993, was opened at 2005-10-03 12:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311993&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Hinrichs (ben-hin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python breakdown in windows (uses apsw)

Initial Comment:
I got this breakdown after a coding error. My mistake
is pretty obvious, but the fact that the python crashes
might interest you. Not sure it's not a problem with
apsw though.

I send a command:
cur.execute("select * from tasks where anum=?")

Later corrected to:
cur.execute("select * from tasks where anum=?",(yadda,))

I've included the source which breaks python for me.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311993&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311993 ] Python breakdown in windows (uses apsw)

[SourceForge.net]

Bugs item #1311993, was opened at 2005-10-03 17:47
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311993&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parser/Compiler
Group: Python 2.4
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Benjamin Hinrichs (ben-hin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python breakdown in windows (uses apsw)

Initial Comment:
I got this breakdown after a coding error. My mistake
is pretty obvious, but the fact that the python crashes
might interest you. Not sure it's not a problem with
apsw though.

I send a command:
cur.execute("select * from tasks where anum=?")

Later corrected to:
cur.execute("select * from tasks where anum=?",(yadda,))

I've included the source which breaks python for me.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-03 18:25

Message:
Logged In: YES 
user_id=1188172

With the latest version of apsw, this doesn't happen for me.
If it still does for you, I would suspect apsw though since
it is a C extension and as such prone for subtle programming
errors.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311993&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes

[SourceForge.net]

Bugs item #1311784, was opened at 2005-10-03 12:18
Message generated for change (Comment added) made by pete_icoserve
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Klotz (pete_icoserve)
Assigned to: Nobody/Anonymous (nobody)
Summary: python.exe 2.4.2 compiled with VS2005 crashes

Initial Comment:
The C runtime library shipped with Visual Studio 2005
performs strict checking of parameters.

In function initsignal() in file
Modules\signalmodule.c, an iteration over all signals
from 1 to NSIG is performed.

The function PyOS_getsig() is called with each of these
integer values. PyOS_getsig() then calls signal() with
the given value which leads to the crash.

According to signal.h from VS2005 only these signals
are allowed:

#define SIGINT  2 
#define SIGILL  4 
#define SIGABRT_COMPAT  6 
#define SIGFPE  8 
#define SIGSEGV 11
#define SIGTERM 15
#define SIGBREAK21
#define SIGABRT 22

A solution would be to restrict the loop in
initsignal() to the above values under Windows.

--

>Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-03 18:10

Message:
Logged In: YES 
user_id=299547

VS2005 is still not released. 

It is scheduled for November 7th 2005. I tested with CTP 
(Community Technology Preview) August 2005.

However I doubt they will change the behavior of their C library 
at this point of development.

--

Comment By: Michael Hudson (mwh)
Date: 2005-10-03 13:05

Message:
Logged In: YES 
user_id=6656

Is VS2005 actually out now then?  This behaviour violates the C standard, 
as far as we can tell, so we when VS2005 was in beta we hoped that they 
would fix it for the final release.

If it is released, though, I guess we need to do something like you suggest 
(along with some colourful comments, I guess).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1019808 ] wrong socket error returned

[SourceForge.net]

Bugs item #1019808, was opened at 2004-08-31 13:18
Message generated for change (Comment added) made by fgsch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Schwindt (fgsch)
Assigned to: Nobody/Anonymous (nobody)
Summary: wrong socket error returned

Initial Comment:
hi,

  first, background:

  OS: OpenBSD-current/i386
  Python version: 2.3.4

   example script:

import socket

socket.setdefaulttimeout(30)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', ))

   where nothing is listening on  (ECONNREFUSED
should be returned).
   when ran it i get:

Traceback (most recent call last):
  File "bug.py", line 8, in ?
s.connect(('127.0.0.1', ))
  File "", line 1, in connect
socket.error: (22, 'Invalid argument')

  this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
  this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux).
  please contact me if you need further details,
although i find this very clear.
  thanks,

  f.-


--

>Comment By: Federico Schwindt (fgsch)
Date: 2005-10-03 16:44

Message:
Logged In: YES 
user_id=50493

patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 03:02

Message:
Logged In: YES 
user_id=33168

Can you provide a patch that you believe corrects this problem?

--

Comment By: Federico Schwindt (fgsch)
Date: 2005-06-24 06:41

Message:
Logged In: YES 
user_id=50493

just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(

--

Comment By: Federico Schwindt (fgsch)
Date: 2004-09-23 00:58

Message:
Logged In: YES 
user_id=50493

any news? this may be a problem in other *BSDs as well..

--

Comment By: Federico Schwindt (fgsch)
Date: 2004-08-31 13:22

Message:
Logged In: YES 
user_id=50493

maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.

f.-

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1019808 ] wrong socket error returned

[SourceForge.net]

Bugs item #1019808, was opened at 2004-08-31 09:18
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Schwindt (fgsch)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: wrong socket error returned

Initial Comment:
hi,

  first, background:

  OS: OpenBSD-current/i386
  Python version: 2.3.4

   example script:

import socket

socket.setdefaulttimeout(30)

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', ))

   where nothing is listening on  (ECONNREFUSED
should be returned).
   when ran it i get:

Traceback (most recent call last):
  File "bug.py", line 8, in ?
s.connect(('127.0.0.1', ))
  File "", line 1, in connect
socket.error: (22, 'Invalid argument')

  this is a problem in the socketmodule.c, in the
internal_connect() function. getsockopt with SOCK_ERROR
should be used once EINPROGRESS is returned to get the
real error.
  this code works on linux, but the connect semantic
is, imho, broken. you cannot reuse a socket once it
failed (a test afterwards shown that this is valid
under linux).
  please contact me if you need further details,
although i find this very clear.
  thanks,

  f.-


--

Comment By: Federico Schwindt (fgsch)
Date: 2005-10-03 12:44

Message:
Logged In: YES 
user_id=50493

patch against 2.4.1 appended. not tested in anything but
openbsd. nevertheless, i think it should work in linux and
osx. not sure about others.
cheers.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 23:02

Message:
Logged In: YES 
user_id=33168

Can you provide a patch that you believe corrects this problem?

--

Comment By: Federico Schwindt (fgsch)
Date: 2005-06-24 02:41

Message:
Logged In: YES 
user_id=50493

just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and
the problem is still there :-(

--

Comment By: Federico Schwindt (fgsch)
Date: 2004-09-22 20:58

Message:
Logged In: YES 
user_id=50493

any news? this may be a problem in other *BSDs as well..

--

Comment By: Federico Schwindt (fgsch)
Date: 2004-08-31 09:22

Message:
Logged In: YES 
user_id=50493

maybe i was not clear. the problem is only happening when
setdefaulttimeout is used. otherwise ECONNREFUSED is
correctly returned.

f.-

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1311784 ] python.exe 2.4.2 compiled with VS2005 crashes

[SourceForge.net]

Bugs item #1311784, was opened at 2005-10-03 05:18
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Klotz (pete_icoserve)
Assigned to: Nobody/Anonymous (nobody)
Summary: python.exe 2.4.2 compiled with VS2005 crashes

Initial Comment:
The C runtime library shipped with Visual Studio 2005
performs strict checking of parameters.

In function initsignal() in file
Modules\signalmodule.c, an iteration over all signals
from 1 to NSIG is performed.

The function PyOS_getsig() is called with each of these
integer values. PyOS_getsig() then calls signal() with
the given value which leads to the crash.

According to signal.h from VS2005 only these signals
are allowed:

#define SIGINT  2 
#define SIGILL  4 
#define SIGABRT_COMPAT  6 
#define SIGFPE  8 
#define SIGSEGV 11
#define SIGTERM 15
#define SIGBREAK21
#define SIGABRT 22

A solution would be to restrict the loop in
initsignal() to the above values under Windows.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 12:54

Message:
Logged In: YES 
user_id=33168

Do you suggest this be special cased for VS2005 specifically
or Windows in general (ie, any version/compiler)?

--

Comment By: Peter Klotz (pete_icoserve)
Date: 2005-10-03 11:10

Message:
Logged In: YES 
user_id=299547

VS2005 is still not released. 

It is scheduled for November 7th 2005. I tested with CTP 
(Community Technology Preview) August 2005.

However I doubt they will change the behavior of their C library 
at this point of development.

--

Comment By: Michael Hudson (mwh)
Date: 2005-10-03 06:05

Message:
Logged In: YES 
user_id=6656

Is VS2005 actually out now then?  This behaviour violates the C standard, 
as far as we can tell, so we when VS2005 was in beta we hoped that they 
would fix it for the final release.

If it is released, though, I guess we need to do something like you suggest 
(along with some colourful comments, I guess).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1311784&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1307806 ] PCbuild vcproj project files need a cleanup

[SourceForge.net]

Bugs item #1307806, was opened at 2005-09-29 03:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: PCbuild vcproj project files need a cleanup

Initial Comment:
The Visual Studio .NET vcproj files were probably
generated by importing the older Visual C++ 6.0 dsp
files and saving them back into the new format. The
convertor is not perfect. The bigest problem it has
it's the handling of the configuration macro defines.
Instead of defining the used macros once for each
configuration, it defines them for each individual
file. This causes file bloat and could cause problems
when new files are added to the project since we could
get builds with mixed defines due to the $(NoInherit)
flag which makes the compiler ignore global defines.

For example, the current pythoncore.vcproj file has 100
KB. A cleaned up version is less than 25 KB.

NOW:












CLEANED-UP:



There are a couple of files which require custom options:

..\Modules\getbuildinfo.c - 
PreprocessorDefinitions="BUILD=67"

..\PC\import_nt.c - 
AdditionalIncludeDirectories="..\Python"


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 12:56

Message:
Logged In: YES 
user_id=33168

Can you provide a patch (attach to this bug report if
possible) for what the new file should look like?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1245381 ] log() on a big number fails on powerpc64

[SourceForge.net]

Bugs item #1245381, was opened at 2005-07-26 11:38
Message generated for change (Comment added) made by heffler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
Assigned to: Nobody/Anonymous (nobody)
Summary: log() on a big number fails on powerpc64

Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected 
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 15:06

Message:
Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
   log(x) + log(2) * e * SHIFT.
   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
   so force use of double. */
+   printf("", (e * (double)SHIFT));
x = func(x) + (e * (double)SHIFT) * func(2.0);
return PyFloat_FromDouble(x);
}

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 01:36

Message:
Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1245381 ] log() on a big number fails on powerpc64

[SourceForge.net]

Bugs item #1245381, was opened at 2005-07-26 12:38
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
Assigned to: Nobody/Anonymous (nobody)
Summary: log() on a big number fails on powerpc64

Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected 
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

--

>Comment By: Tim Peters (tim_one)
Date: 2005-10-03 16:18

Message:
Logged In: YES 
user_id=31435

When you add a print and the problem goes away, the cause 
is almost certainly an optimization bug in the C compiler you 
used to compile the module.

Try compiling mathmodule.c with optimization turned off.  I 
bet that makes the problem go away.  If so, you should 
report the optimization bug to your compiler vendor (you 
didn't say which C compiler you're using, BTW).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 16:06

Message:
Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
   log(x) + log(2) * e * SHIFT.
   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
   so force use of double. */
+   printf("", (e * (double)SHIFT));
x = func(x) + (e * (double)SHIFT) * func(2.0);
return PyFloat_FromDouble(x);
}

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 02:36

Message:
Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1245381 ] log() on a big number fails on powerpc64

[SourceForge.net]

Bugs item #1245381, was opened at 2005-07-26 09:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
Assigned to: Nobody/Anonymous (nobody)
Summary: log() on a big number fails on powerpc64

Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected 
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 13:18

Message:
Logged In: YES 
user_id=33168

That makes me wonder if it's a compiler issue.  Can you try
building without optimization and see if that fixes your
problem?  What are the compiler flags used?

--

Comment By: Tim Peters (tim_one)
Date: 2005-10-03 13:18

Message:
Logged In: YES 
user_id=31435

When you add a print and the problem goes away, the cause 
is almost certainly an optimization bug in the C compiler you 
used to compile the module.

Try compiling mathmodule.c with optimization turned off.  I 
bet that makes the problem go away.  If so, you should 
report the optimization bug to your compiler vendor (you 
didn't say which C compiler you're using, BTW).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 13:06

Message:
Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
   log(x) + log(2) * e * SHIFT.
   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
   so force use of double. */
+   printf("", (e * (double)SHIFT));
x = func(x) + (e * (double)SHIFT) * func(2.0);
return PyFloat_FromDouble(x);
}

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:36

Message:
Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1245381 ] log() on a big number fails on powerpc64

[SourceForge.net]

Bugs item #1245381, was opened at 2005-07-26 11:38
Message generated for change (Comment added) made by heffler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
Assigned to: Nobody/Anonymous (nobody)
Summary: log() on a big number fails on powerpc64

Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected 
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 16:01

Message:
Logged In: YES 
user_id=298758

I think both you guys are right that this appears to be a 
compiler issue. I am using gcc 3.4.3. The compiler flags 
being used were "-DNDEBUG -g -O3 -Wall -Wstrict-
prototypes". When I redid the build with the -O3 removed 
everything worked fine with log. I'm going to pass this 
problem on to the gcc folks for them to investigate.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 15:18

Message:
Logged In: YES 
user_id=33168

That makes me wonder if it's a compiler issue.  Can you try
building without optimization and see if that fixes your
problem?  What are the compiler flags used?

--

Comment By: Tim Peters (tim_one)
Date: 2005-10-03 15:18

Message:
Logged In: YES 
user_id=31435

When you add a print and the problem goes away, the cause 
is almost certainly an optimization bug in the C compiler you 
used to compile the module.

Try compiling mathmodule.c with optimization turned off.  I 
bet that makes the problem go away.  If so, you should 
report the optimization bug to your compiler vendor (you 
didn't say which C compiler you're using, BTW).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 15:06

Message:
Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
   log(x) + log(2) * e * SHIFT.
   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
   so force use of double. */
+   printf("", (e * (double)SHIFT));
x = func(x) + (e * (double)SHIFT) * func(2.0);
return PyFloat_FromDouble(x);
}

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-30 01:36

Message:
Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail

[ python-Bugs-1245381 ] log() on a big number fails on powerpc64

[SourceForge.net]

Bugs item #1245381, was opened at 2005-07-26 09:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1245381&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jiri Dluhos (jdluhos)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: log() on a big number fails on powerpc64

Initial Comment:
The log() function seems to give incorrect results for
large numbers on a 64-bit powerpc architecture. The
test_math program from the Python test suite fails with
the following message:

math module, testing with eps 1e-05
constants
acos
asin
atan
atan2
ceil
cos
cosh
degrees
exp
fabs
floor
fmod
frexp
hypot
ldexp
log
Traceback (most recent call last):
  File "test_math.py", line 117, in ?
testit('log(10**40, 10)', math.log(10**40, 10), 40)
  File "test_math.py", line 13, in testit
raise TestFailed, '%s returned %f, expected 
%f'%test.test_support.TestFailed: log(10**40, 10) returned
21.938200, expected 40.00

Tested on a SMP IBM PowerPC machine, with Python 2.3.4
(64-bit build).

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 14:10

Message:
Logged In: YES 
user_id=33168

Closing this bug as it seems to be gcc related.  Thanks for
your comments.

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 14:01

Message:
Logged In: YES 
user_id=298758

I think both you guys are right that this appears to be a 
compiler issue. I am using gcc 3.4.3. The compiler flags 
being used were "-DNDEBUG -g -O3 -Wall -Wstrict-
prototypes". When I redid the build with the -O3 removed 
everything worked fine with log. I'm going to pass this 
problem on to the gcc folks for them to investigate.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 13:18

Message:
Logged In: YES 
user_id=33168

That makes me wonder if it's a compiler issue.  Can you try
building without optimization and see if that fixes your
problem?  What are the compiler flags used?

--

Comment By: Tim Peters (tim_one)
Date: 2005-10-03 13:18

Message:
Logged In: YES 
user_id=31435

When you add a print and the problem goes away, the cause 
is almost certainly an optimization bug in the C compiler you 
used to compile the module.

Try compiling mathmodule.c with optimization turned off.  I 
bet that makes the problem go away.  If so, you should 
report the optimization bug to your compiler vendor (you 
didn't say which C compiler you're using, BTW).

--

Comment By: Marvin Heffler (heffler)
Date: 2005-10-03 13:06

Message:
Logged In: YES 
user_id=298758

I have tried this with python 2.4, 2.4.1, and now 2.4.2. All of 
them face the same problem where log won't work correctly 
on ppc64. The same code works just fine for me on ia32, 
ia64, ppc32, s390, s390x, and x86_64. Only ppc64 sees the 
problem.

The problem can be reproduced easily on a ppc64 system 
with python having been built as a 64-bit binary. Just start 
python in interactive mode and enter the following commands:

   >>import math
   >>math.log(10**40, 10)

The correct answer is 40, but on ppc64 the result comes 
back as 21.938200260161128. I'm not very familiar with the 
python source code, but with a little playing I came up with a 
way to correct the problem. I don't know why the problem 
gets resolved, but it does. By adding a simple printf near the 
end of the loghelper function in Modules/mathmodule.c, the 
problem goes away. Here's a diff showing the change I made 
to get things working correctly:

--- mathmodule.c.SAV2005-10-03 12:56:38.468014112 -
0500
+++ mathmodule.c2005-10-03 12:57:35.192044904 -
0500
@@ -224,6 +224,7 @@
   log(x) + log(2) * e * SHIFT.
   CAUTION:  e*SHIFT may overflow using int 
arithmetic,
   so force use of double. */
+   printf("", (e * (double)SHIFT));
x = func(x) + (e * (double)SHIFT) * func(2.0);
return PyFloat_FromDouble(x);
}

Maybe someone who is more familiar with the python code 
can figure out why a change like this would make a difference.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 23:36

Message:
Logged In: YES 
user_id=33168

Can you test with newer versions of Python, preferrably 
2.4.2 or current CVS?  2.3.4 worked for me on 64-bit Opteron.

-

[ python-Bugs-1307806 ] PCbuild vcproj project files need a cleanup

[SourceForge.net]

Bugs item #1307806, was opened at 2005-09-29 13:08
Message generated for change (Comment added) made by adalx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
Assigned to: Nobody/Anonymous (nobody)
Summary: PCbuild vcproj project files need a cleanup

Initial Comment:
The Visual Studio .NET vcproj files were probably
generated by importing the older Visual C++ 6.0 dsp
files and saving them back into the new format. The
convertor is not perfect. The bigest problem it has
it's the handling of the configuration macro defines.
Instead of defining the used macros once for each
configuration, it defines them for each individual
file. This causes file bloat and could cause problems
when new files are added to the project since we could
get builds with mixed defines due to the $(NoInherit)
flag which makes the compiler ignore global defines.

For example, the current pythoncore.vcproj file has 100
KB. A cleaned up version is less than 25 KB.

NOW:












CLEANED-UP:



There are a couple of files which require custom options:

..\Modules\getbuildinfo.c - 
PreprocessorDefinitions="BUILD=67"

..\PC\import_nt.c - 
AdditionalIncludeDirectories="..\Python"


--

>Comment By: Adal Chiriliuc (adalx)
Date: 2005-10-04 00:32

Message:
Logged In: YES 
user_id=1067739

Attached patch with cleaned up .vcproj files.

VCCLCompilerTool: removed PrecompiledHeaderFile,
AssemblerListingLocation, ObjectFile,
ProgramDataBaseFileName entires. They are defined by default
to the same values.

VCMIDLTool: removed all entries.

VCResourceCompilerTool: removed all entries for all but a
couple of projects which actually have resource files.

Removed FileConfiguration entries for all project files
which don't need it.

There's still stuff which could be cleaned up, I've only
removed the biggest offenders.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:56

Message:
Logged In: YES 
user_id=33168

Can you provide a patch (attach to this bug report if
possible) for what the new file should look like?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1307806&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-973103 ] empty raise after handled exception

[SourceForge.net]

Bugs item #973103, was opened at 2004-06-15 02:36
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Neal Norwitz (nnorwitz)
Summary: empty raise after handled exception

Initial Comment:
executing empty raise after handled exception produces
wrong traceback.

no exception:

Traceback (most recent call last):
  File "bug.py", line 19, in ?
test(i)
  File "bug.py", line 15, in test
badfn()
  File "bug.py", line 5, in badfn
raise
TypeError: exceptions must be classes, instances, or
strings (deprecated), not NoneType

handled exception:

no
Traceback (most recent call last):
  File "bug.py", line 19, in ?
test(i)
  File "bug.py", line 15, in test
badfn()
  File "bug.py", line 11, in test
print d[12345]
KeyError: 12345


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 20:45

Message:
Logged In: YES 
user_id=33168

Ok, Raymond fixed the problem.  The wording is now:

raise re-raises the last exception that was active in the
current scope.  If no exception is active in the current
scope, a TypeError exception is
raised indicating that this is an error (if running under
IDLE, a Queue.Empty exception is raised instead).

I fixed Armins problem with continue.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-03 05:59

Message:
Logged In: YES 
user_id=4771

Sorry, my mistake.  I confused the try: part and the finally: part of the 
try:finally:.  You can use 'continue' in the former but not in the latter.

I don't see off-hand a deep problem in supporting 'continue' in the finally: 
part, which probably means that I am not thinking hard enough.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 21:38

Message:
Logged In: YES 
user_id=33168

Armin, your comment about continue says that it's not
illegal inside a try/finally?  Is that exactly correct? 
continue can be used inside a try, except, else, but not
finally from my testing.  Is that correct?

I agree that the wording of 7.4 is still not correct.  The
try should be changed to a finally.  Should the laziness
comment be removed?  Should continue be allowed inside a
finally?  Does the exception get eatten like return inside a
finally?

6.9 needs some work too.  I asked Raymond about some of the
current wording which he seems to have modified last.

--

Comment By: Armin Rigo (arigo)
Date: 2004-06-24 03:06

Message:
Logged In: YES 
user_id=4771

This is the intended behavior, although the docs that explain that are not too 
clear: "raise" is equivalent to re-raising what "sys.get_info()" returns; the 
docs about sys.get_info() explain in detail why you get this behavior.

The language reference 6.9 should mention this.  (Btw the language reference 
7.4 still says that continue is illegal within try:finally:, which is no longer 
the case.)

The reason sys.get_info() has access to the exception handled in a parent frame 
is to be able to implement things like traceback.print_exc().  But I don't know 
exactly why it should be the case that an exception remains active after its 
handler finished.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=973103&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1262856 ] fcntl.ioctl have a bit problem.

[SourceForge.net]

Bugs item #1262856, was opened at 2005-08-18 01:53
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Raise L. Sail (fullsail)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: fcntl.ioctl have a bit problem.

Initial Comment:
First, I write python program on Linux.

The function ioctl of fcntl module, take a integer
parameter
as ioctl command. in python 2.3.x, if this command
value is more than 0x8000, interpreter will popup
some warnning message. but in python 2.4.x, it raise a
exception directly.

My solution is writing one cutoms module in C. but this
is so ugly.

There are some ioctl command value are more than
0x8000,  I think we should not reject "negative"
ioctl command.

enjoy.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 21:49

Message:
Logged In: YES 
user_id=33168

This could be related to: patch 1309352.

--

Comment By: Michael Hudson (mwh)
Date: 2005-08-23 05:10

Message:
Logged In: YES 
user_id=6656

I think this is fixed in CVS HEAD.  Can you try that?

As a workaround, you can probably pass ~int(~v&0x) to ioctl 
instead of v (which is very ugly, yes, but probably not as ugly as a C 
extension).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1262856&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-914148 ] xml.sax segfault on error

[SourceForge.net]

Bugs item #914148, was opened at 2004-03-11 06:14
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 6
Submitted By: Adam Sampson (adamsampson)
Assigned to: Neal Norwitz (nnorwitz)
Summary: xml.sax segfault on error

Initial Comment:
While (mistakenly) using Mark Pilgrim's feedparser
module to parse data from
,
Python segfaults when it should invoke an error handler
for invalid XML. The attached code demonstrates the
problem; it occurs with Python 2.2.3 and 2.3.3 on my
system. I've tried to chop the example data down as far
as possible, but reducing it any further doesn't
exhibit the problem (it's currently just above 64k,
which might be a coincidence).

The gdb traceback I get from the example is as follows:

#0  normal_updatePosition (enc=0x404a4fc0, 
ptr=0x40682000 , 
end=0x81e87e0 "a>\n\n\n\n\n

[ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser

[SourceForge.net]

Bugs item #1246405, was opened at 2005-07-27 16:07
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jean-Pierre (jean-pierre24)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault when importing expat from xml.parser

Initial Comment:
 Hello,

I have a strange segmentation fault when importing
expat from xml.parsers in the following program (I
removed all that is un-necessary to reproduce the bug,
which is why the code may look odd).

I've also posted this bug on wxPython bug lists because
I'm not sure if it's related to Python or wxPython, but
anyway the backtrace told me that the segmentation
fault occurs when importing expat.

import wx
import wx.html

class MainFrame(wx.Frame):
def __init__(self, prnt):
wx.Frame.__init__(self, parent=prnt)
wx.html.HtmlWindow(wx.Window(self, -1), -1)
print "debug 1"
from xml.parsers import expat
print "debug 2"

class BoaApp(wx.App):
def OnInit(self):
wx.InitAllImageHandlers()
MainFrame(None)
return True

app = BoaApp()

The segmentation fault occurs between 'debug 1' and
'debug 2'. If I try to remove anything else, it doesn't
happen.
I have confirmed the bug on SunOS 5.8, on linux Red Hat
Enterprise Server 3 and linux Advanced Server 3.
I'm working with Python 2.4.1 and wxPython 2.6.1.0
Here is in attached file, the backtrace from gdb.

Feel free to ask me any additional information...


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:10

Message:
Logged In: YES 
user_id=33168

Can you provide a link to the wx bug report?  Has anything
happend with it?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1241545 ] garbage collection asserts failing

[SourceForge.net]

Bugs item #1241545, was opened at 2005-07-20 06:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1241545&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: munder12 (munder12)
Assigned to: Nobody/Anonymous (nobody)
Summary: garbage collection asserts failing

Initial Comment:
Modules/gcmodule.c:294: visit_reachable: Assertion
`gc_refs > 0 || gc_refs == (-3) || gc_refs == (-2)' failed.

Running Python 2.3.4 on Fedora Core 3 (2.6.11-1.35_FC3smp).
Also tried Python 2.3.5.

When searching Google for this error, found following
link where someone using yum updates was getting same
error from python

http://forums.fedoraforum.org/showthread.php?t=54704



--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:13

Message:
Logged In: YES 
user_id=33168

munder, do you think this is still a bug or should it be closed?

--

Comment By: munder12 (munder12)
Date: 2005-07-25 05:55

Message:
Logged In: YES 
user_id=1156202

Well, I have what appears to be a working solution:  Use
python 2.5a0 from CVS.  This version works with psyco.  I
suspect the bug fix to gcmodules.c that added the missing
INCREF is the culprit (the one labelled as a backport
candidate).

As for why the assert was triggering, I have my thoughts. 
First, gdb when trying to read the core files was confirming
the absolute path to the (non-debug) executable I thought I
was running but also would not give a valid traceback due to
stack corruption.  Is it possible that the memory corruption
was making it where (__ASSERT_VOID_CAST (0)) was unable to
succeed?  (This is what assert(expr) is macro'd to when
defining NDEBUG.)

Thanks.

--

Comment By: Tim Peters (tim_one)
Date: 2005-07-21 11:25

Message:
Logged In: YES 
user_id=31435

This part of the command line you showed:

-DNDEBUG

causes C's assert() macro to "expand to nothing".  That's 
part of the definition of the C language, not a Python 
convention.  So if you compiled Python with -DNDEBUG, and 
are seeing an assert() trigger, then I can only conclude one of 
two things:

1. Your C compiler has a very bad bug.

or

2. You're not actually using the Python you think you're using.

That said, I've seen very strange bugs triggered by psyco too, 
but not even psyco can cause code to execute that doesn't 
exist.  No code is generated for an assert() when compiling 
with -DNDEBUG:  the C preprocessor throws assert()s away 
when NDEBUG is #define'd.

--

Comment By: munder12 (munder12)
Date: 2005-07-21 11:05

Message:
Logged In: YES 
user_id=1156202

Well, this gets even stranger.  I am not running a debug
version of python as far as I can tell.

I built 2.4.1 in a fresh directory by:
./configure --prefix=/blah
make
make test
make install

The gcmodule was echo'd as being built this way:
gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -I. -I./Include  -DPy_BUILD_CORE -o
Modules/gcmodule.o Modules/gcmodule.c

I am leaning toward psyco as being the culprit based on your
suggestions since it is the only one that has extra C libraries.

I'm running the case with Tkinter, pyro, and psyco all not
being imported.

Thanks again,
Mark

--

Comment By: Tim Peters (tim_one)
Date: 2005-07-20 17:35

Message:
Logged In: YES 
user_id=31435

I'm intimately familiar with the gc code, and I'm sure this 
assert has never triggered in any core Python release, or in 
any Zope release, not even in between-releases buggy 
development states.

It means some memory gc is staring at has an insane value, 
one that can't possibly arise in intended operation.  If you get 
into gdb (whatever debugger you have), it might be useful to 
know what value gc_refs _does_ have at this point.

One possibility is that you're mixing a debug-build Python 
(which you are using:  asserts never trigger in a release-build 
Python, simply because the assert() macro expands to 
nothing then) with one or more release-build extension 
modules.  Trying to mix like that can blow up in all sorts 
of "impossible" ways.

--

Comment By: munder12 (munder12)
Date: 2005-07-20 17:04

Message:
Logged In: YES 
user_id=1156202

Sorry, I realize it is not much to go on but I cannot currently 
get it to fail other than when I run this one script.  It is all 
written in python.  It is a simulation running a gen

[ python-Bugs-1193099 ] Embedded python thread crashes

[SourceForge.net]

Bugs item #1193099, was opened at 2005-04-30 12:03
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: ugodiggi (ugodiggi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded python thread crashes

Initial Comment:
The following code crashes about 1/3 of the times. 

My platform is Python 2.4.1 on WXP (I tried the release
version from the msi and the debug version built by me). 
I can reproduce the same behavior on another wxp
system, under python 2.4. 

The crash happens (in the python thread) while the main
thread is in Py_Finalize. 
I traced the crash to _Py_ForgetReference(op) in
object.c at line 1847, where I have op->_ob_prev == NULL. 

The open file seems to be the issue, since if I remove
all the references to the file I cannot get the program
to crash.

Cheers and ciao 

Ugo 

// TestPyThreads.cpp
// 
#include  // Sleep
#include "Python.h" 

int main() 
{ 
PyEval_InitThreads(); 
Py_Initialize(); 
PyGILState_STATE main_restore_state =
PyGILState_UNLOCKED; 
PyGILState_Release(main_restore_state); 

// start the thread 
{ 
PyGILState_STATE state =
PyGILState_Ensure(); 
int trash = PyRun_SimpleString( 
"import thread\n" 
"import time\n" 
"def foo():\n" 
"  f =
open('pippo.out', 'w', 0)\n" 
"  i = 0;\n" 
"  while 1:\n" 
"f.write('%d\n'%i)\n" 
"time.sleep(0.01)\n" 
"i += 1\n" 
"t =
thread.start_new_thread(foo, ())\n" 
); 
PyGILState_Release(state); 
} 

// wait 300 ms 
Sleep(300); 

PyGILState_Ensure(); 
Py_Finalize(); 
return 0; 
} 
 


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:37

Message:
Logged In: YES 
user_id=33168

I can't reproduce on gentoo linux (amd64) with a debug
build.  I played with different values for sleep.  BTW, it
would be better if you attached the code as a file, since
formatting is lost.

Can you try to debug this problem?
Can you attach info from the debugger?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193099&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1191726 ] about shift key

[SourceForge.net]

Bugs item #1191726, was opened at 2005-04-28 07:38
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191726&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: yang (leeews)
Assigned to: Nobody/Anonymous (nobody)
Summary: about shift key

Initial Comment:
I'v wrote the following program
--
from Tkinter import *

class KeyDemo(Frame):
""

def __init__(self):
""

Frame.__init__(self)
self.pack(expand=YES,fill=BOTH)
self.master.title("Demonstrating Keystroke Events")
self.master.geometry("350x100")

self.message1=StringVar()
self.line1=Label(self,textvariable=self.message1)
self.message1.set("Type any key or shift")
self.line1.pack()

self.message2=StringVar()
self.line2=Label(self,textvariable=self.message2)
self.message2.set("")
self.line2.pack()

self.master.bind("",self.keyPressed)
self.master.bind("",self.keyReleased)

   
self.master.bind("",self.shiftPressed)
   
self.master.bind("",self.shiftReleased)

def keyPressed(self,event):
""

self.message1.set("Key pressed: "+ event.char)
self.message2.set("This key is not left shift")

def keyReleased(self,event):
""

self.message1.set("Key released: "+ event.char)
self.message2.set("This key is not left shift")

def shiftPressed(self,event):
""

self.message1.set("Shift pressed")
self.message2.set("This key is left shift")

def shiftReleased(self,event):
""

self.message1.set("Shift released")
self.message2.set("This key is left shift")

def main():
KeyDemo().mainloop()

if __name__=="__main__":
main()

--
When I pressed right shift , it shows:
 Key pressed:
This key is not left shift

And when I released right shift ,it shows:
Shift released
This key is left shift
But what I release is right shift.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:38

Message:
Logged In: YES 
user_id=33168

In order to preserve formatting, it's best to attach a file
which contains the problem.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 13:07

Message:
Logged In: YES 
user_id=1188172

I can reproduce this here with Py2.4.1 on WinXP.
With Py2.4.1/2.3.5 and Tk 8.4.9 using Linux, there's no problem.

Could this be a Tk problem?

In any case, updating metadata.

--

Comment By: yang (leeews)
Date: 2005-04-29 04:47

Message:
Logged In: YES 
user_id=1268579

sorry,I'll be minimize my code sample next time

my code had formatted correctly when I edit it,but when I
post it , The spaces for format control had disappeared.

my platform is python 2.4 /winXP

This is the first time I report bug, so I don't know what is
the correct way. sorry to trouble you

--

Comment By: Ilya Sandler (isandler)
Date: 2005-04-28 17:46

Message:
Logged In: YES 
user_id=971153

This seems like a bug (not a patch) report..

So I guess it might be a good idea to close it and refile as
a bug...

And a few more suggestions:

  --try to minimize your code sample 
  --make sure that your sample code is formatted correctly
in your post
  --please indicate what platform/OS you are using

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1191726&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1175194 ] import statement likely to crash if module launches threads

[SourceForge.net]

Bugs item #1175194, was opened at 2005-04-01 21:11
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175194&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
Summary: import statement likely to crash if module launches threads

Initial Comment:
I have a simple module which launches multiple HTTP client threads.

The main thread creates 10 HTTP clients, each of which fetches 
documents from a web server.  The main thread then simply goes to 
sleep while the client threads work. The threads are launched when 
the module is imported.

If I launch the script via
  python bug1.py
it launches and runs OK, and dies cleanly upon ^C.

But if I launch the script via
  python -c 'import bug1'
it hangs at launch, and dumps core upon ^C.

Here's an example:

[EMAIL PROTECTED]> ./python -c 'import bug1'
Using 10 threads
cc  <- [program hangs here]
Traceback (most recent call last):
  File "", line 1, in ?
  File "test/bug1.py", line 55, in ?
run (10)
  File "test/bug1.py", line 50, in run
time.sleep (3)
KeyboardInterrupt
Fatal Python error: PyImport_GetModuleDict: no module dictionary!
Aborted (core dumped)

You might argue that it's inappropriate to launch threads from within  
import statement, but I can't find a specific prohibition against it.

In any event, it shouldn't cause the interpreter to crash.

Please note that the crash isn't consistent. Sometimes the import 
statement doesn't lead to a crash.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-03 22:42

Message:
Logged In: YES 
user_id=33168

Reproduced on Linux.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1175194&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com