[ python-Bugs-1239120 ] Win registry problem

[SourceForge.net]

Bugs item #1239120, was opened at 2005-07-15 21:46
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1239120&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: Installation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Bruce Sherwood (bsherwood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Win registry problem

Initial Comment:
Debbie Carraway in IT at NCSU gives this analysis of an
apparent bug in the Python 2.4 installer for Windows.
She discovered this in the context of using the
installer for VPython, which looks for Python 2.4 in

  HKLM\Software\Python\PythonCore\2.4\InstallPath

which used to work with Python 2.3. Here is her report:

The problem is with the Python 2.4.1 installer. Python will
put the InstallPath registry setting (which indicates where
Python is installed)  under HKEY_CURRENT_USER instead of
HKEY_LOCAL_MACHINE under some circumstances:
 (1) if you are not a member of the Administrators group
 (2) if you choose "Install for Just Me" rather than
"Install for All Users",
 (3) if you automate the Python install using "msiexec.exe
/i python-2.4.1.msi /q". The /q (quiet) switch causes
different behavior than the defaults with a manual install
("msiexec.exe /i python-2.4.1.msi").

This is a mistake in the Python installer. The path to an
installed application always belongs under HKLM,
because the
path to installed software is a machine-specific
setting. If
the path is in HKCU, the InstallPath setting can follow a
user to a machine where Python is not installed.

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-10-01 19:11

Message:
Logged In: YES 
user_id=1188172

As far as I can see, newer installers (created with
bdist_wininst) will look in both registry keys for Python
versions.

So I think a new VPython installer should solve this problem.

--

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

[ python-Bugs-1308042 ] Datagram Socket Timeouts

[SourceForge.net]

Bugs item #1308042, was opened at 2005-09-29 10:05
Message generated for change (Comment added) made by tvrankar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&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: Works For Me
Priority: 5
Submitted By: Tom Vrankar (tvrankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datagram Socket Timeouts

Initial Comment:
Python 2.4.1, MS Windows 2000 with service packs

I'm trying to have a UDP client check for its server to
start by repeatedly throwing messages at where it's
expected to appear, and then checking for a response. I
set a timeout on the recvfrom, expecting to block for
the timeout and then proceeding to an exception
handler, looping so until data is returned. Instead,
the recvfrom throws an immediate exception "Connection
reset by peer", and I loop rapidly without the
load-softening effect of the timeout (in fact, it's the
same behavior as if I didn't set the timeout at all).
What UDP "connection" is it talking about?

Seems wrong, but is it the implementation or is it me?
If I start the server first, I get one "Invalid
argument" exception in the client. In both cases, once
the server is started, both processes are satisfied.

Thanks.

twv

--

>Comment By: Tom Vrankar (tvrankar)
Date: 2005-09-30 13:50

Message:
Logged In: YES 
user_id=1353485

With Python around, I don't program much in C anymore, and
for the same reason I usually assume platform independence
(ensured by some clever Python programmer -- C or lib --
spackling over minor underlying differences) unless the
Python docs explicitly tell me otherwise. nnorwitz's Linux
results match my Solaris 8 results (and are what I
intended). I submitted this report since the docs didn't
provide any warnings about Python's UDP sockets behaving
differently per platform. The behavior I saw would be wacky
even on Windoze, but I don't know just how tolerant Windoze
developers are of a poor sockets implementation :-).

--

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

Message:
Logged In: YES 
user_id=33168

This is a dupe of 1307357, but I'm closing that one since
most of the comments are here.  However, note this one
comment from twv in the other report that says it also works
on Solaris 8 and could well be Windoze specific.


--

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

Message:
Logged In: YES 
user_id=33168

Can you program the client in C and see if it behaves the
same?  Sockets are mostly just wrappers around the OS calls.
 It's possible this is the expected behaviour on Windows and
python is just exposing that to you.

I ran this on Linux and got this (which is what I think you
want):

[EMAIL PROTECTED] clean $ ./python PyBug/client.py &
[1] 31484
[EMAIL PROTECTED] clean $ timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
./python PyBug/server.py
timed out
timed out

timed out
('127.0.0.1', 40899) says CHECK
('127.0.0.1', 3000) says OK
[10587 refs]
[10585 refs]
[1]+  Done./python PyBug/client.py


--

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

[ python-Bugs-772896 ] unknown encoding -> MemoryError

[SourceForge.net]

Bugs item #772896, was opened at 2003-07-17 03:27
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772896&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: unknown encoding -> MemoryError

Initial Comment:
If you try to install a program and one of the files 
declares an unknown encoding(like 'UFT-8'),
byte-compiling the file fails and get the message, "Sorry: 
MemoryError: ()"

This message obscures the problem and makes it difficult 
to spot the problem.
In fact, it took me a while to find out that the unknown 
encoding declaration caused the trouble.

The error message needs to be more explicit.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-01 18:52

Message:
Logged In: YES 
user_id=33168

I fixed this problem in 2.5.  I am leaving it up to Anthony
whether to backport this to 2.4 or not.

Checked in as:
Misc/NEWS: 1.1383, 1.1193.2.117
Python/pythonrun.c: 2.217, 2.211.2.3
Lib/test/bad_coding.py: 1.1
Lib/test/test_coding.py: 1.1
Parser/parsetok.c: 2.37
Parser/pgenmain.c: 2.32
Parser/tokenizer.c: 2.79


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772896&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 03:05
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 13: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 01: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 22: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 12: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-1219273 ] 'Expression' AST Node not documented

[SourceForge.net]

Bugs item #1219273, was opened at 2005-06-12 11:27
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1219273&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: Martin Miller (mrmiller)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: 'Expression' AST Node not documented

Initial Comment:
Python 2.4.1 documentation
===
The table at the end of section "19.3.1 AST Nodes" 
does not list Node type 'Expression' and its associated
information.

Also, the BNF for 'expression' shown in the file


> expression ::= 
>  or_test | lambda_form

can't be correct because it doesn't cover cases of a
simple literals (or identifiers) such as 42 and simple
binary operator expressions such as 1+2.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 17:37

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * lib/asttable.tex 1.3

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 12:26

Message:
Logged In: YES 
user_id=174455

See patch #1227568

--

Comment By: Peter van Kampen (pterk)
Date: 2005-06-29 12:24

Message:
Logged In: YES 
user_id=174455

I have submitted a (very minimal) doc-patch that adds
expression to the section 19.3.1.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-18 13:34

Message:
Logged In: YES 
user_id=1188172

To your second comment: the BNF for expression is correct
since or_test can contain and_test which can contain
not_test and so on until primary, atom, literal.

--

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

[ python-Bugs-1308042 ] Datagram Socket Timeouts

[SourceForge.net]

Bugs item #1308042, was opened at 2005-09-29 07:05
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1308042&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: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tom Vrankar (tvrankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Datagram Socket Timeouts

Initial Comment:
Python 2.4.1, MS Windows 2000 with service packs

I'm trying to have a UDP client check for its server to
start by repeatedly throwing messages at where it's
expected to appear, and then checking for a response. I
set a timeout on the recvfrom, expecting to block for
the timeout and then proceeding to an exception
handler, looping so until data is returned. Instead,
the recvfrom throws an immediate exception "Connection
reset by peer", and I loop rapidly without the
load-softening effect of the timeout (in fact, it's the
same behavior as if I didn't set the timeout at all).
What UDP "connection" is it talking about?

Seems wrong, but is it the implementation or is it me?
If I start the server first, I get one "Invalid
argument" exception in the client. In both cases, once
the server is started, both processes are satisfied.

Thanks.

twv

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 17:44

Message:
Logged In: YES 
user_id=33168

I added a note near the top of the socket module doc. 

"""Some behavior may be platform dependent, since calls are
made to the operating system socket APIs."""

Let me know if you think something more needs to be done.

Checked in as:
 * Doc/lib/libsocket.tex 1.90, 1.88.2.2

--

Comment By: Tom Vrankar (tvrankar)
Date: 2005-09-30 10:50

Message:
Logged In: YES 
user_id=1353485

With Python around, I don't program much in C anymore, and
for the same reason I usually assume platform independence
(ensured by some clever Python programmer -- C or lib --
spackling over minor underlying differences) unless the
Python docs explicitly tell me otherwise. nnorwitz's Linux
results match my Solaris 8 results (and are what I
intended). I submitted this report since the docs didn't
provide any warnings about Python's UDP sockets behaving
differently per platform. The behavior I saw would be wacky
even on Windoze, but I don't know just how tolerant Windoze
developers are of a poor sockets implementation :-).

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:43

Message:
Logged In: YES 
user_id=33168

This is a dupe of 1307357, but I'm closing that one since
most of the comments are here.  However, note this one
comment from twv in the other report that says it also works
on Solaris 8 and could well be Windoze specific.


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-29 22:30

Message:
Logged In: YES 
user_id=33168

Can you program the client in C and see if it behaves the
same?  Sockets are mostly just wrappers around the OS calls.
 It's possible this is the expected behaviour on Windows and
python is just exposing that to you.

I ran this on Linux and got this (which is what I think you
want):

[EMAIL PROTECTED] clean $ ./python PyBug/client.py &
[1] 31484
[EMAIL PROTECTED] clean $ timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
timed out
./python PyBug/server.py
timed out
timed out

timed out
('127.0.0.1', 40899) says CHECK
('127.0.0.1', 3000) says OK
[10587 refs]
[10585 refs]
[1]+  Done./python PyBug/client.py


--

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

[ python-Bugs-887946 ] segfault if redirecting directory

[SourceForge.net]

Bugs item #887946, was opened at 2004-01-30 16:42
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887946&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.4
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Inyeol Lee (inyeol)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: segfault if redirecting directory

Initial Comment:
If redirecting directory, python crashes.

$ uname -a
SunOS x 5.8 Generic_108528-18 sun4u sparc
SUNW,Sun-Blade-1000
$ python
Python 2.3.2 (#1, Oct  9 2003, 18:59:04) 
[GCC 2.95.3 20010315 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> ^D
$ mkdir foo
$ ls -F
foo/
$ python < foo
Segmentation Fault

-Inyeol Lee

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 18:05

Message:
Logged In: YES 
user_id=33168

I fixed this problem and also added a warning when passing a
directory on the command line.  Before the fix, python would
just silently exit which just bit me recently.  (Same as
mbp's comment.)

Checked in as:
 * Misc/NEWS: 1.1384, 1.1193.2.118
 * Modules/main.c: 1.85, 1.84.2.1
 * Python/sysmodule.c: 2.130, 2.126.2.4
 * Lib/test/test_cmd_line.py: 1.1, 1.1.2.2


--

Comment By: Martin Pool (mbp)
Date: 2005-06-05 22:32

Message:
Logged In: YES 
user_id=521

Here is another failure, which might have the same root cause:

$ python /tmp
$ echo $?
0

I'd expect this to give an error.

--

Comment By: Martin Pool (mbp)
Date: 2005-06-05 22:20

Message:
Logged In: YES 
user_id=521

I doubt if libc checks whether the input is a directory;
there are possible (though extremely obscure) cases where
you might want to do that.

I think you probably need something along the lines of
fstat(0, &buf), then check the st_mode.  Remember that fifos
and chardevs ought to be allowed.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 04:32

Message:
Logged In: YES 
user_id=1038590

Python's C main function assumes stdin, stdout and stderr
are all valid FILE pointers.

A little experimentation on a Linux box should establish
what glibc is providing when the input pipe isn't a proper
file (probably stdin == NULL given the symptoms, but that's
just a guess)

A sanity check on stdin should then be possible near the
start of the main function.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-11-22 04:24

Message:
Logged In: YES 
user_id=1038590

Win XP SP 1 - 

C:\Python24>python < Lib
"Access is Denied"

--

Comment By: Inyeol Lee (inyeol)
Date: 2004-11-04 11:10

Message:
Logged In: YES 
user_id=595280

I did some more test among different versions;
2.4b1/Solaris - segfault
2.3.3/Linux - segfault
2.3.2/Solaris - segfault
2.1.1/Linux - OK
1.5.2/Linux - OK


--

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

[ python-Bugs-814259 ] LDFLAGS ignored in Makefile

[SourceForge.net]

Bugs item #814259, was opened at 2003-09-28 20:51
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814259&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.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Randy Davis (randydavis1)
Assigned to: Neal Norwitz (nnorwitz)
Summary: LDFLAGS ignored in Makefile

Initial Comment:
Under IRIX 6.3 gcc 3.2.2, building python results in the 
normal IRIX o32/n32 stupidity. However, attempting to 
correct it by specifying LDFLAGS of -n32 is ignored.  
Inspecting the Makefile produced by configure shows 
that the environment variable LDFLAGS is properly 
imported and is set as the environment variable is set (in 
this case; "LDFLAGS = -n32").  **HOWEVER**, it is 
NEVER used on any "ld" command line.

I was able to fix it by changing the lines:

LDSHARED=   ld  -shared -all
BLDSHARED=  ld  -shared -all

to:

LDSHARED=   ld  -shared -all $(LDFLAGS)
BLDSHARED=  ld  -shared -all $(LDFLAGS)

While I do not profess that this is the best way to fix it, 
I do note that the LDFLAGS Makefile variable seems to 
be ignored unless this is done.  Making this change got 
rid of the FATAL ld errors complaining about expecting 
o32 binaries but getting n32 versions.

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 18:06

Message:
Logged In: YES 
user_id=33168

Looking in Makefile.pre.in I see that LDFLAGS is used to
link with.  If you are still having problems, please re-open.

--

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

Message:
Logged In: YES 
user_id=33168

Looking in Makefile.pre.in I see that LDFLAGS is used to
link with.  If you are still having problems, please re-open.

--

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

[ python-Bugs-898271 ] symtable module crashes w/ coding declaration

[SourceForge.net]

Bugs item #898271, was opened at 2004-02-16 12:49
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=898271&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: Open
Resolution: None
Priority: 5
Submitted By: Peter Åstrand (astrand)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: symtable module crashes w/ coding declaration

Initial Comment:
The symtable module doesn't work with source code
encodings, it seems. Sample code:

#!/usr/bin/env python
# -*- coding: iso-8859-1 -*-

import sys
import symtable
filename = sys.argv[0]
tab = symtable.symtable(open(filename).read(),
filename, exec")
print tab.get_type()

When running this code, I get:

Traceback (most recent call last):
  File "./bar.py", line 8, in ?
print tab.get_type()
  File "/usr/local/lib/python2.3/symtable.py", line 71,
in get_type
assert self._table.type in (1, 2, 3), AssertionError: unexpected type: 0

If I remove the source code encoding declaration,
things work fine. I've verified this problem with 2.3.2
and 2.3.3. 2.2.0 and 2.2.2 works fine. 

--

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

Message:
Logged In: YES 
user_id=33168

This is still a problem w/2.5.

--

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

[ python-Bugs-904474 ] File read of Chinese utf-16-le treats upper byte 1A as EOF

[SourceForge.net]

Bugs item #904474, was opened at 2004-02-25 11:30
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=904474&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: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ron Rother (rrother)
Assigned to: Nobody/Anonymous (nobody)
Summary: File read of Chinese utf-16-le treats upper byte 1A as EOF

Initial Comment:
Any utf-16-le Chinese character with 1A as the most 
significant byte causes remainder of file to be ignored.

code extract:

(utf16_encoder, utf16_decoder, utf16_reader, 
utf16_writer) = codecs.lookup("utf-16-le")

ifile = utf16_reader(open(sys.argv[1],"r"))

t=ifile.read()

When the Chinese character 1A 5C (尚) is encoundered, 
everthing from the 5C is discarded.

These 3 lines:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="尚未选择任何书卷！"

are input as:
English="You have not selected any books!"
Context=1,[MsgBox "You have not selected any books!"]
Chinese(Simplified)="

--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 18:19

Message:
Logged In: YES 
user_id=33168

MAL, this seems to come up from time to time.  Perhaps we
should update the doc for open()?  If it's already
documented, could we make it clearer?  Then we should be
able to close this bug.  I think I saw another bug recently
that was similar to this one.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-25 14:53

Message:
Logged In: YES 
user_id=38388

I believe there is a misconception here: the open(..., "r")
will cause the file to be opened in C lib's text mode. Since
UTF-16 is binary data, this will lead to problems with line
breaking
and file handling in general.

You should try:

import codecs
ifile = codecs.open(filename, 'rb', encoding='utf-16-le')


--

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

[ python-Bugs-906405 ] Build fails on XP w/mingw

[SourceForge.net]

Bugs item #906405, was opened at 2004-02-28 03:08
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&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.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Con (shrodingersdog)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Build fails on XP w/mingw

Initial Comment:
When trying to build the source:

Modules/posixmodule.c fails to build.

I'm running on XP SP1 using 
mingw32-make ver 3.80

Is there any known issues on XP?


--

Comment By: Con (shrodingersdog)
Date: 2005-06-27 04:26

Message:
Logged In: YES 
user_id=986333

Still, happens. In the end I just compiled the source using 
VC6, so it doesn't really matter for me anymore though. 

It might be that I just don't have the MinGW environment 
setup right...

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 04:57

Message:
Logged In: YES 
user_id=1188172

Is this still happening with 2.3.5 or 2.4.1?

--

Comment By: Con (shrodingersdog)
Date: 2004-05-01 03:52

Message:
Logged In: YES 
user_id=986333

Sorry, crash is not the right word.
I've attached the output from make.

Let me know if that helps or if you need other info.


--

Comment By: Martin v. Löwis (loewis)
Date: 2004-04-24 01:08

Message:
Logged In: YES 
user_id=21627

What exactly does "it crashes" mean? Do you get a blue
screen? Is your hard disk making a crashing sound?

--

Comment By: Con (shrodingersdog)
Date: 2004-04-23 02:27

Message:
Logged In: YES 
user_id=986333

When I run make it crashes when it gets to 
Modules/posixmodule.c.
This is compiling with the Ming / (Cygwin?) compiler though.

I have recently tried with MSVC 6 which builds without any 
problems.


--

Comment By: Martin v. Löwis (loewis)
Date: 2004-03-29 14:35

Message:
Logged In: YES 
user_id=21627

In what way precisely does it fail?

It builds fine for me with VC.NET 2003, which is the
official build environment for Python on XP.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&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 (Comment added) 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: 5
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\nComment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 18:26

Message:
Logged In: YES 
user_id=33168

This doesn't crash for me on 2.5 (CVS) (2.4 seems about the
same), but there is use of uninitialized memory in valgrind.
 (It does crash when running under valgrind.)  Either way,
there is still a problem.

Do you still see the crash?

==26881== Use of uninitialised value of size 8
==26881==at 0x12BA4518: normal_updatePosition
(xmltok_impl.c:1745)
==26881==by 0x12B91005: XML_GetCurrentLineNumber
(xmlparse.c:1782)
==26881==by 0x12B884EA: set_error (pyexpat.c:125)
==26881==by 0x12B8BCCD: get_parse_result (pyexpat.c:901)
==26881==by 0x12B8BD6A: xmlparse_Parse (pyexpat.c:923)
==26881==by 0x4E00B0: PyCFunction_Call (methodobject.c:73)
==26881==by 0x48B2F3: call_function (ceval.c:3580)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x48B76E: fast_function (ceval.c:3673)
==26881==by 0x48B436: call_function (ceval.c:3601)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x4DF7FA: function_call (funcobject.c:548)
==26881==by 0x418DE2: PyObject_Call (abstract.c:1777)
==26881==
==26881== Invalid read of size 1
==26881==at 0x12BA4514: normal_updatePosition
(xmltok_impl.c:1745)
==26881==by 0x12B91005: XML_GetCurrentLineNumber
(xmlparse.c:1782)
==26881==by 0x12B884EA: set_error (pyexpat.c:125)
==26881==by 0x12B8BCCD: get_parse_result (pyexpat.c:901)
==26881==by 0x12B8BD6A: xmlparse_Parse (pyexpat.c:923)
==26881==by 0x4E00B0: PyCFunction_Call (methodobject.c:73)
==26881==by 0x48B2F3: call_function (ceval.c:3580)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x48B76E: fast_function (ceval.c:3673)
==26881==by 0x48B436: call_function (ceval.c:3601)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x4DF7FA: function_call (funcobject.c:548)
==26881==by 0x418DE2: PyObject_Call (abstract.c:1777)
==26881==  Address 0x12B720C0 is 0 bytes after a block of
size 131072 alloc'd
==26881==at 0x11B19F13: malloc (vg_replace_malloc.c:149)
==26881==by 0x12B90AB5: XML_GetBuffer (xmlparse.c:1634)
==26881==by 0x12B906B0: XML_Parse (xmlparse.c:1528)
==26881==by 0x12B8BD5F: xmlparse_Parse (pyexpat.c:923)
==26881==by 0x4E00B0: PyCFunction_Call (methodobject.c:73)
==26881==by 0x48B2F3: call_function (ceval.c:3580)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x48B76E: fast_function (ceval.c:3673)
==26881==by 0x48B436: call_function (ceval.c:3601)
==26881==by 0x486F4C: PyEval_EvalFrameEx (ceval.c:2181)
==26881==by 0x48932B: PyEval_EvalCodeEx (ceval.c:2754)
==26881==by 0x4DF7FA: function_call (funcobject.c:548)
==26881==by 0x418DE2: PyObject_Call (abstract.c:1777)
==26881==by 0x421034: instancemethod_call
(classobject.c:2447)


--

Comment By: Jozef Behran (jojoworks)
Date: 2004-04-03 11:28

Message:
Logged In: YES 
user_id=688090

Now when I thinked out a way how to put a breakpoint into
shared library and get GDB stopped on it I investigated on
this bug more and found following:

The bug is in XML_GetBuffer() located at xmlparse.c:1498.
When this call realizes that the buffer is too small, a
larger one is allocated and data are copied. The problem is
that m_eventPtr is not transformed to be pointing into the
new buffer during

[ python-Bugs-941346 ] AIX shared library fix

[SourceForge.net]

Bugs item #941346, was opened at 2004-04-24 08:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=941346&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: Dick Dunbar (dickdunbar)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX shared library fix

Initial Comment:
By default, the ld command only looks for *.a archives
to resolve library references.

To recognize dynamic shared libaries (*.so), two flags
need to be added to the Modules/ld_so_aix script: -brtl
-bnortllib

Line 170 in the script should read:

CCOPT="$CCOPT -Wl,-bM:SRE -Wl,-T512 -Wl,-H512 -brtl
-bnortllib -lm -o $objfile"

-brtl ... says you want to include libtk8.4.so 
   when searching for the library -ltk8.4

-bnortllib ... says you do not want the semantics of
the AIX "run time linking" services ... just the search
for the library.

This resolves a problem when Python is built with tk
support.


--

>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-02 20:58

Message:
Logged In: YES 
user_id=33168

I added a comment based on the above information.  I don't
want to make a real change, since I can't test it.  If we
get access to some AIX boxes, we could really fix.  I'm
hestitant to break stuff without testing.

Checked in as:

Modules/ld_so_aix 2.6

--

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

[ python-Bugs-962226 ] Python 2.3.4 on Linux: test test_grp failed

[SourceForge.net]

Bugs item #962226, was opened at 2004-05-28 07:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=962226&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: Open
Resolution: None
Priority: 5
Submitted By: Michael Ströder (stroeder)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.3.4 on Linux: test test_grp failed

Initial Comment:
Build on SuSE Linux 9.0:

test test_grp failed -- Traceback (most recent call last):
  File
"/home/michael/src/Python-2.3.4/Lib/test/test_grp.py",
line 71, in test_errors
self.assertRaises(KeyError, grp.getgrnam, fakename)
  File
"/home/michael/src/Python-2.3.4/Lib/unittest.py", line
295, in failUnlessRaises
raise self.failureException, excName
AssertionError: KeyError


--

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

Message:
Logged In: YES 
user_id=33168

Michael, can you provide some more info?

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-06-11 09:55

Message:
Logged In: YES 
user_id=29957

Can you see if the patch on http://www.python.org/sf/775964
 fixes this?

I have had this patch sitting in my source tree for Some
Time, waiting for time to test it. :-/


--

Comment By: Michael Ströder (stroeder)
Date: 2004-05-28 07:43

Message:
Logged In: YES 
user_id=64920

I do not use NIS. But I don't know what SuSE really puts
into the "compat" NSS module.

>From my /etc/nsswitch.conf:

passwd: compat
group:  compat


--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-05-28 07:26

Message:
Logged In: YES 
user_id=29957

Do you use YP/NIS? If so, this is a known problem, and is
documented on the bugs page for 2.3.4. I really should get
around to checking those fixes in...


--

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

[ python-Bugs-963321 ] Acroread aborts printing PDF documentation

[SourceForge.net]

Bugs item #963321, was opened at 2004-05-30 16:50
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963321&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: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Howard B. Golden (hgolden)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Acroread aborts printing PDF documentation

Initial Comment:
Using acroread 5.08 under Linux 2.6.5, the May 20, 2004
version of the documentation (release 2.3.4) is
displayed successfully. However, when I attempt to
print the documentation, acroread aborts (prints
"Aborted" on standard error).

(It is possible that this is an acroread bug, but I'm
reporting it here in case it indicates a problem with
PDF files generated by the documentation building process.)

--

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

Message:
Logged In: YES 
user_id=33168

Howard, do you still have this problem?

--

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

[ 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 03:03
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 21: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 14: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-971213 ] another threads+readline+signals nasty

[SourceForge.net]

Bugs item #971213, was opened at 2004-06-11 08:30
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 21: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 02: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 14:41

Message:
Logged In: YES 
user_id=6656

Bah, this still segfaults with CVS head.

--

Comment By: Michael Hudson (mwh)
Date: 2004-06-21 03: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 08: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 08: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 08: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-971238 ] test_timeout failure on trunk

[SourceForge.net]

Bugs item #971238, was opened at 2004-06-11 09:07
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&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.4
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: test_timeout failure on trunk

Initial Comment:
On current-CVS trunk, Fedora Core 2:

testBlockingThenTimeout (__main__.CreationTestCase) ... ok
testFloatReturnValue (__main__.CreationTestCase) ... ok
testObjectCreation (__main__.CreationTestCase) ... ok
testRangeCheck (__main__.CreationTestCase) ... ok
testReturnType (__main__.CreationTestCase) ... ok
testTimeoutThenBlocking (__main__.CreationTestCase) ... ok
testTypeCheck (__main__.CreationTestCase) ... ok
testAcceptTimeout (__main__.TimeoutTestCase) ... ok
testConnectTimeout (__main__.TimeoutTestCase) ... FAIL
testRecvTimeout (__main__.TimeoutTestCase) ... ok
testRecvfromTimeout (__main__.TimeoutTestCase) ... ok
testSend (__main__.TimeoutTestCase) ... ok
testSendall (__main__.TimeoutTestCase) ... ok
testSendto (__main__.TimeoutTestCase) ... ok

==
FAIL: testConnectTimeout (__main__.TimeoutTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than
expected (%g)"
AssertionError: timeout (13.3079) is more than 2
seconds more than expected (0.001)

--
Ran 14 tests in 36.437s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_timeout.py", line 192, in ?
test_main()
  File "Lib/test/test_timeout.py", line 189, in test_main
test_support.run_unittest(CreationTestCase,
TimeoutTestCase)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 290, in run_unittest
run_suite(suite, testclass)
  File
"/home/anthony/src/py/pyhead/dist/src/Lib/test/test_support.py",
line 275, in run_suite
raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent
call last):
  File "Lib/test/test_timeout.py", line 121, in
testConnectTimeout
"timeout (%g) is more than %g seconds more than
expected (%g)"
AssertionError: timeout (13.3079) is more than 2
seconds more than expected (0.001)


--

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

Message:
Logged In: YES 
user_id=33168

Anthony, ping?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-06 17:27

Message:
Logged In: YES 
user_id=80475

Anthony, is this still a valid report?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971238&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: 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: 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-976608 ] Unhelpful error message when mtime of a module is -1

[SourceForge.net]

Bugs item #976608, was opened at 2004-06-21 02:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=976608&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: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Peter Maxwell (pm67nz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Unhelpful error message when mtime of a module is -1

Initial Comment:
This fragment of import.c:

  mtime = PyOS_GetLastModificationTime(pathname, fp);
  if (mtime == (time_t)(-1))
 return NULL;

is missing a PyErr_SetString(), so in at least one circumstance (an 
__init__.py file with an apparent mtime of 1 Jan 1970 created by a 
bug in darcs on debian linux) it produces "SystemError: NULL 
result without error in PyObject_Call".

--

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

Message:
Logged In: YES 
user_id=33168

Thanks for the info, you were correct.

Checked in as:
 * Misc/NEWS something large, 1.1193.2.119
 * Python/import.c 2.245, 2.240.2.3

--

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

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

[SourceForge.net]

Bugs item #979739, was opened at 2004-06-25 06:45
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 22: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 14: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 12: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-991735 ] os.access reports true for read-only directories

[SourceForge.net]

Bugs item #991735, was opened at 2004-07-15 10:08
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=991735&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: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Moales (mmoales)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: os.access reports true for read-only directories

Initial Comment:
It appears that os.access incorrectly reports write 
access to directories on network drives.  For example, if 
I have a read-only directory called foo\bar on a machine 
called homeserver, the following code always returns 
true:

print os.access("\\homeserver\foo\bar", os.W_OK)
True

Similarly, if I map above directory to a drive, the results 
are the same, i.e.:

print os.access("H:\bar", os.W_OK)
True

However, if I try to create a file in that directory, I get 
a permission error:

f = file("h:\foo\bar\test.txt", 'w+b')
Traceback (most recent call last):
  File "", line 1, in ?
IOError: [Errno 13] Permission 
denied: 'h:\foo\bar\test.txt'

--

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

Message:
Logged In: YES 
user_id=33168

Done.  It only took a year plus :-(.

Thanks for the note.

Checked in as:
 * Doc/lib/libos.tex 1.168, 1.146.2.11

--

Comment By: Mike Coleman (mkc)
Date: 2004-08-02 21:39

Message:
Logged In: YES 
user_id=555

nnorwitz: The penultimate paragraph of my comment (the one
that begins "Note that...") is what I'd suggest adding to
the doc...


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-08-02 15:18

Message:
Logged In: YES 
user_id=33168

Mark or mkc, can you suggest wording to improve the docs? 
Thanks.

--

Comment By: Mike Coleman (mkc)
Date: 2004-07-29 12:28

Message:
Logged In: YES 
user_id=555

The submitter seems to want os.access to agree with the
subsequent behavior of I/O operation, but this is not
possible for all cases.  The NFS spec, for example, allows
NFS servers to deny operations in a capricious manner, over
and above any denial that might be due to permissions bits
and/or a volume "read only" flag.  I don't know if there is
an SMB/CIFS server spec, but one could imagine the same
thing happening there.

It might be possible to add ACL checking to the Windows
version of os.access, if a Windows person thinks it's
worthwhile.  It probably would be valuable to add a
clarification to the os.access doc.  For example:

Note that I/O operations may fail even when the access
function indicates that they would succeed, particularly for
operations on network filesystems, which may have
permissions semantics beyond the usual POSIX permission-bit
model.

(Also, if someone does this, please update the doc to note
that access returns True and False, not 1 and 0.)

--

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 13:59

Message:
Logged In: YES 
user_id=31435

Heh -- I didn't know it either, Thomas.  But I've also noticed 
how many new Windows bugs get assigned to you, and got 
curious enough to dig into it.

--

Comment By: Mark Moales (mmoales)
Date: 2004-07-15 12:25

Message:
Logged In: YES 
user_id=565165

This may not be a bug afterall.  I think it has to do with 
Window's ACLs.  I believe os.access is just looking at access 
bits.  For example, I can create a directory and leave it as 
writable, but prevent access to it via an ACL.  In this case, 
os.access reports true, but any operation you try to perform 
on the dictionary get's a permission error.  It might just need 
to be mentioned in the os.access doc.

Thomas: no problem

--

Comment By: Thomas Heller (theller)
Date: 2004-07-15 12:20

Message:
Logged In: YES 
user_id=11105

Tim: I didn't know that.  Thanks for disabling it.

Mark: Sorry, it wasn't your fault.

--

Comment By: Tim Peters (tim_one)
Date: 2004-07-15 11:56

Message:
Logged In: YES 
user_id=31435

The tracker was set to auto-assign Windows reports to you, 
Thomas.  I disabled that (and Windows reports will be 
assigned to None by default now).

--

Comment By: Thomas Heller (theller)
Date: 2004-07-15 11:41

Message:
Logged In: YES 
user_id=11105

Please don't assign windows bugs to me.  Thanks.

--

[ python-Bugs-992017 ] code that generates a segfault on Python 2.1-2.3

[SourceForge.net]

Bugs item #992017, was opened at 2004-07-15 16:56
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&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.4
Status: Open
Resolution: None
>Priority: 7
Submitted By: Ted Bach (bachtor)
Assigned to: Nobody/Anonymous (nobody)
Summary: code that generates a segfault on Python 2.1-2.3

Initial Comment:
On a Redhat Linux 9 based system, the following causes
a segfault:


""" In python, you can call any expression.
"""

class foo:
  def __init__(s,times=1):
 s.times = times
  def __call__(s): print s.times
  def __mul__(s,o): return foo(o)
  def __coerce__(s,o):
if isinstance(o,int):
  return o,s


(foo(3)*10)()   # no segfault
 
(10*foo(3))()   # segfaults
# prints 10

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-08 10:26

Message:
Logged In: YES 
user_id=1188172

Still persists with Python 2.4.

--

Comment By: Armin Rigo (arigo)
Date: 2004-08-07 14:44

Message:
Logged In: YES 
user_id=4771

Here is a shorter example:

  class foo:
  def __coerce__(self, other):
  return other, self
  foo()+1   # segfault: infinite recursion in C

classobject.c seems hopelessly prone to infinite recursion in C: whenever an 
operation needs coercion, __coerce__ is called and the operator PyNumber_Xxx() 
is called again on the result.  The most obvious cases of recursion are taken 
care of, but there are and will always be more convoluted ways to create this 
recursion.

There might be a way to solve the problem cleanly but currently I only see the 
solution of adding a C recursion check (Py_EnterRecursiveCall / 
Py_LeaveRecursiveCall).

--

Comment By: Dima Dorfman (ddorfman)
Date: 2004-07-22 07:18

Message:
Logged In: YES 
user_id=908995

This is not the same problem as bug #980352; this one is an infinite recusion 
in the instance code (deriving foo from object makes the example work).

--

Comment By: Michael Hudson (mwh)
Date: 2004-07-16 06:45

Message:
Logged In: YES 
user_id=6656

Isn't this likely to be a dup of bug 

[ 980352 ] coercion results used dangerously

?  I haven't thought about either very hard, but both involve 
__coerce__ and core dumps...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=992017&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 14:21
Message generated for change (Comment added) made by nnorwitz
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: Open
Resolution: None
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 22:19

Message:
Logged In: YES 
user_id=33168

Skip, is this still a problem?

--

Comment By: Gregory P. Smith (greg)
Date: 2004-12-13 04: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 19:22

Message:
Logged In: YES 
user_id=44345

I rebuilt it with 3.3, but noticed something I had missed when
it compiled before:

gcc -pthread -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-fno-strict-aliasing -I/usr/local/BerkeleyDB.3.2/include -I. 
-I/home/skip/src/Python-2.3.4/./Include -I/usr/local/include 
-I/h

[ python-Bugs-1002465 ] MemoryError on AIX52

[SourceForge.net]

Bugs item #1002465, was opened at 2004-08-03 01:04
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1002465&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Datranet (richardjmason)
Assigned to: Nobody/Anonymous (nobody)
Summary: MemoryError on AIX52

Initial Comment:
I found the orginal problem when trying to send large 
email attachments on AIX 5.2. I tracked the issue down 
to the fact that a string can only grow to a very 
restricted size on AIX 5.2. bin2ascii fails at the pint the 
function tries to join the list togther to form 1 string.

I wrote the following test program to prove the issue:

a = ''
cnt = 0

while cnt < 1024:
 a = a + 'x'
 cnt += 1

c = ''
cnt = 0

while cnt < 1024:
 c = c + a
 cnt += 1

b = ''
cnt2 = 0

while 1:
   b = b + c
   cnt2 += 1
   print cnt2

On AIX 5.2 you get a MemoryError with a cnt2 value of 
42. I can run the test program on all other platforms and 
get a cnt2 value over 150 before stopping to program 
myself.

I have tried the binary python 2.2 from the IBM site and 
building python 2.3.4 myself using the gcc from the IBM 
site. Both fail with a cnt2 value of 42.

Can anyone please advise on how to get AIX 5.2 to 
allow single objects to have more memory allocated.

--

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

Message:
Logged In: YES 
user_id=33168

richardjmason, are you still having this problem?

--

Comment By: Michael Hudson (mwh)
Date: 2004-08-05 04:59

Message:
Logged In: YES 
user_id=6656

A way this has happened in the past is calling "malloc(0)",
which is entitled to return NULL and Python then thinks this
is a memory error.  This doesn't seeme especially likely
here, though.  Agree with Martin that you're probably going
to need to use a debugger.

--

Comment By: Martin v. Löwis (loewis)
Date: 2004-08-04 11:09

Message:
Logged In: YES 
user_id=21627

You need to use a debugger to find the cause of the problem.
What is the string parameter of the MemoryError? This might
give a clue where precisely it is raised.

--

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

[ python-Bugs-1008310 ] os.major() os.minor() example and description change

[SourceForge.net]

Bugs item #1008310, was opened at 2004-08-12 15:21
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1008310&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: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Steven (grayshark)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: os.major() os.minor() example and description change

Initial Comment:
The description for os.major() and os.minor() are damn
poor.
major(  device)
Extracts a device major number from a raw device
number. New in version 2.3. 

minor(  device)
Extracts a device minor number from a raw device
number. New in version 2.3. 

The really bad part is the term "raw device number". 

it should be:
Extracts a device [major,minor] number for stat st_rdev
field, or returns a zero if the st_rdev does not
reference a special block device.

Example follows.

--

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

Message:
Logged In: YES 
user_id=33168

Thanks.  I tweaked the wording slightly, based on both of
the comments.  I tried to make it a bit more descriptive and
allude to the system dependent behaviour:

Extracts the device major number from a raw device number
(usually \member{st_dev} or \member{st_rdev} field from
\ctype{stat}).

Let me know if there are any more suggestions.

Checked in as:
 * Doc/lib/libos.tex 1.169, 1.146.2.12

--

Comment By: Dima Dorfman (ddorfman)
Date: 2004-08-18 02:56

Message:
Logged In: YES 
user_id=908995

The proposed description is incorrect. st_rdev is not the
only place to get this value; st_dev comes to mind, and
those interested in these values are likely to be playing
with other system interfaces anyway, so implying a coupling
with st_rdev would be a mistake. I haven't found any
documentation suggesting that major and minor return 0 if
the input is invalid, and since none of these operations are
standardized, we shouldn't document what are platform-
specific semantics. My recent posting on the topic to
comp.lang.python ("using os.major") said, in part,

  The documentation for os.stat mentions st_rdev, but it
  doesn't call it the "raw" device number. The FreeBSD
  documentation is about evenly split on calling it the "raw
  device number" or the "device ID", but Posix uses the
  latter, and I think that makes more sense. There's nothing
  raw about this value; I think it's only "raw" compared to
  internal kernel structures, where a device could be a
  pointer to struct instead of an integer (it's certainly
  not more raw than st_dev, which has the same type).

Accordingly, it might be good to change the documentation
for all of these things to consistently use the term "device
ID" instead of "raw device number". That might still be
poor, but it's as much as can be said for these operations
on all platforms. I'll submit a patch for that in a few days
unless someone beats me to it.

--

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

[ python-Bugs-963321 ] Acroread aborts printing PDF documentation

[SourceForge.net]

Bugs item #963321, was opened at 2004-05-30 23:50
Message generated for change (Comment added) made by hgolden
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963321&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: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Howard B. Golden (hgolden)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Acroread aborts printing PDF documentation

Initial Comment:
Using acroread 5.08 under Linux 2.6.5, the May 20, 2004
version of the documentation (release 2.3.4) is
displayed successfully. However, when I attempt to
print the documentation, acroread aborts (prints
"Aborted" on standard error).

(It is possible that this is an acroread bug, but I'm
reporting it here in case it indicates a problem with
PDF files generated by the documentation building process.)

--

>Comment By: Howard B. Golden (hgolden)
Date: 2005-10-03 05:49

Message:
Logged In: YES 
user_id=4869

I tried this again using acroread 7.0.1, which is the
version currently installed on my system. I have no problem.
Therefore, I assume it was an acroread 5.08 problem, not a
problem with the 2.3.4 documentation, and I am closing this bug.

--

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

Message:
Logged In: YES 
user_id=33168

Howard, do you still have this problem?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=963321&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 (Comment added) 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: 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: 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-1027570 ] os.stat errors when using shared drive on XP or NT

[SourceForge.net]

Bugs item #1027570, was opened at 2004-09-13 15:26
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1027570&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.3
Status: Open
Resolution: None
Priority: 5
Submitted By: zeke (zeke_matzke)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.stat errors when using shared drive on XP or NT

Initial Comment:
The problem is when a file is executed from a shared drive
then no letter drive name exists. So the result returned
by os.path.exists(os.getcwd()) does not return true.
Problem exists for both Active State and Idle on windows
for both XP and NT2000: The problem is with os.stat even
though the file open seems to work ok. Notice other
error for Active State Python.

Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200
32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more
information.

IDLE 1.0.2   No Subprocess 
>>> import os
>>> os.getcwd()
'\\Tardis\QCOS'
>>> os.path.exists(os.getcwd())
False
>>> os.stat(os.getcwd())
Traceback (most recent call last):
  File "", line 1, in ?
os.stat(os.getcwd())
OSError: [Errno 2] No such file or directory:
'\\Tardis\QCOS'
>>> 



PythonWin 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond
([EMAIL PROTECTED]) - see 'Help/About
PythonWin' for further copyright information.
>>> Traceback (most recent call last):
  File
"C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\intpyapp.py",
line 332, in OnFileRun
scriptutils.RunScript(None, None, showDlg)
  File
"C:\Python23\Lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
line 259, in RunScript
path = win32ui.FullPath(path)
win32ui: The file name is invalid
win32ui: Error in Command Message handler for command
ID 36864, Code 0
>>> import os
>>> os.getcwd()
'\\Tardis\QCOS'
>>> os.path.exists(os.getcwd())
False
>>> os.stat(os.getcwd())
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 2] No such file or directory:
'\\Tardis\QCOS'
>>>



--

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

Message:
Logged In: YES 
user_id=33168

Can you propose a patch that would correct this problem?

--

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

[ python-Bugs-1029561 ] test_pep277 fails

[SourceForge.net]

Bugs item #1029561, was opened at 2004-09-16 16:24
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1029561&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: Marek Baczynski (imbaczek)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pep277 fails

Initial Comment:
Running regrtest.py:

test_pep277
test test_pep277 produced unexpected output:
**
*** mismatch between line 3 of expected output and line
3 of actual output:
- ['???', '???', '??', '', 'G\xdf',
'Ge??-sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii']
?   ^ 

+ ['???', '???', '-???', '??', '',
'?\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii']
?     
 ^
**

But when running just test_pep277.py:
test_directory (__main__.UnicodeFileTests) ...
u'\xdf-\u66e8\u66e9\u66eb'
ok
test_failures (__main__.UnicodeFileTests) ... ok
test_listdir (__main__.UnicodeFileTests) ... ['???',
'???', '-???', '??', '',
'?\xdf', 'Gr\xfc\xdf-Gott', 'abc', 'ascii']
[u'Gr\xfc\xdf-Gott', u'abc', u'ascii',
u'\u0393\u03b5\u03b9\u03ac-\u03c3\u03b1\u03c2',
u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435',
u'\u05d4\u05e9\u05e7\u05e6\u05e5\u05e1',
u'\u306b\u307d\u3093',
u'\u66e8\u05e9\u3093\u0434\u0393\xdf',
u'\u66e8\u66e9\u66eb']
ok
test_open (__main__.UnicodeFileTests) ... ok
test_rename (__main__.UnicodeFileTests) ... ok

--
Ran 5 tests in 0.109s

OK


--

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

Message:
Logged In: YES 
user_id=33168

I didn't see the fix get propagated back to 2.3.5. Python
2.3 isn't maintained any longer, so I'm going to close this.

--

Comment By: George Yoshida (quiver)
Date: 2005-01-27 12:58

Message:
Logged In: YES 
user_id=671362

Changes against Lib/test/test_pep277.py(Revision 1.9) and 
Lib/test/output/test_pep277(Revision 1.3) ironed out the 
problem with Python 2.4, but the same error can be seen with 
Python 2.3.5 RC1.

Is there any chance that they're backported to 2.3 branch 
before 2.3.5 final gets released?

--

Comment By: Facundo Batista (facundobatista)
Date: 2004-10-20 20:15

Message:
Logged In: YES 
user_id=752496

The tests (through regrtest.py and alone) pass OK to me.

Using (Win2k SP4), Python 2.4b1 (#57, Oct 15 2004, 15:23:38)
[MSC v.1310 32 bit (Intel)] on win32, and:

>>> import locale
>>> locale.getlocale()
['Spanish_Argentina', '1252']

.Facundo

--

Comment By: Miki Tebeka (tebeka)
Date: 2004-10-17 09:06

Message:
Logged In: YES 
user_id=358087

Fails for me on 2.4b1 on winXP

--

Comment By: George Yoshida (quiver)
Date: 2004-09-17 02:55

Message:
Logged In: YES 
user_id=671362

Same for me.
Fail for regrtest.py, but OK for test_277.py in isolation.
(Python 2.4a3, Windows 2K SP4, locale:Japan)

But my output is a bit different from yours.

test test_pep277 produced unexpected output:
**

*** mismatch between line 3 of expected output and line 3 
of actual output:
- ['???', '???', '??', '', 'G\xdf', 'Ge??-
sa?', 'Gr\xfc\xdf-Gott', 'abc', 'ascii']
+ ['??', '??\x82\xf1\x84t\x83\xa1s', '?\x9eG?', 'Grus-
Gott', 'abc', 'ascii', '\x82\xc9\x82\xdb\x82\xf1', '\x83\xa1\x83
\xc3\x83\xc7?-\x83\xd0\x83\xbf?', '\x84H\x84t\x84\x82
\x84p\x84r\x84\x83\x84\x84\x84r\x84\x85\x84z\x84\x84\x84u']
**


This reminds me of the next thread:
* More joy with test_strptime
  http://mail.python.org/pipermail/python-dev/2004-
July/046046.html


--

Comment By: Marek Baczynski (imbaczek)
Date: 2004-09-16 16:25

Message:
Logged In: YES 
user_id=838849

Forgot: Windows XP SP1, Python 2.4a3

--

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

[ python-Bugs-1045509 ] Problems with os.system and ulimit -f

[SourceForge.net]

Bugs item #1045509, was opened at 2004-10-12 08:34
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045509&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.4
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Tomasz Kowaltowski (kowaltowski)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Problems with os.system and ulimit -f

Initial Comment:
Python version (running under Fedora Core 2 Linux):
   Python 2.3.3 (#1, May  7 2004, 10:31:40)
   [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] on linux2
---
I found a problem while executing the 'ulimit -f' bash
command within the 'os.system' function. According to
the documentation this function should behave exactly
like the stdlib function 'system'. However it does not
happen as illustrated by the minimal Python and C
examples: testsystem.py and testsystem.c (see attached
zipped file).

In these examples 'largefile' is a compiled C program
which writes an endless file into the stdout (also
attached). The C program testsystem.c works as expected
and prints the following output:

   command: ulimit -f 10; largefile > xxx;
   result = 153

The Python program testsystem.py **does not stop**; if
interrupted by Ctrl-C it prints:

  command: ulimit -f 10; largefile > xxx;
  result = 0

In both cases the output file 'xxx' has 10240 bytes,
ie, 10 blocks as limited by 'ulimit'. 

It is interesting though that the command 'ulimit -t 1'
(CPU time) produces correct results under both Python
and C versions, ie, interrupts the execution and prints:

  command: ulimit -t 1; largefile > xxx;
  result = 137






--

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

Message:
Logged In: YES 
user_id=33168

It's set in Python/pythonrun.c. The reason is below.  I'm
not sure this can be changed.  Any suggestions?  I'd be
happy to update doc, but have no idea where.  

revision 2.160
date: 2002/04/23 20:31:01;  author: jhylton;  state: Exp; 
lines: +3 -0
Ignore SIGXFSZ.

The SIGXFSZ signal is sent when the maximum file size limit is
exceeded (RLIMIT_FSIZE).  Apparently, it is also sent when
the 2GB
file limit is reached on platforms without large file support.

The default action for SIGXFSZ is to terminate the process
and dump
core.  When it is ignored, the system call that caused the
limit to be
exceeded returns an error and sets errno to EFBIG.  Python
always checks errno on I/O syscalls, so there is nothing to
do with
the signal.


--

Comment By: Gustavo Sverzut Barbieri (gsbarbieri)
Date: 2004-11-26 11:38

Message:
Logged In: YES 
user_id=511989

The problem is that python ignores the SIGXFSZ (File size
limit exceeded) signal.

import signal
signal.signal( signal.SIGXFSZ, signal.SIG_DFL )

solves your problem.


Any python developer: why does python ignores this signal?

--

Comment By: Tomasz Kowaltowski (kowaltowski)
Date: 2004-10-22 04:52

Message:
Logged In: YES 
user_id=185428

I also tested the new version "Python 2.4b1" -- the problem
still occurs :-(.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045509&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 08:50
Message generated for change (Comment added) made by nnorwitz
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: Neal Norwitz (nnorwitz)
Date: 2005-10-02 23: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 01: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 09: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-16 16: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-16 16: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 Hudson (mwh)
Date: 2004-11-16 00:38

Message:
Logged In: YES 
user_id=6656

Hmm.  The traceback shows that it's dumping core while loading 
the site.pyc file from the disk.  This happens before Python begins 
executing whatever code you've asked it to.  You could try 
deleting the site.pyc file and see if that makes any differ