[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "upgrade.py", line 45, in run
returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
 stdin=None, 
stdout=subprocess.PIPE, \
 stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-04-11 07:21

Message:
Logged In: YES 
user_id=1434251

I looked at the patch #1467770 you mentioned and 
downloaded the patch.

Is it correct that _deadlock variable is used in the 
definition of poll but it is not in the argument list?


--

Comment By: cheops (atila-cheops)
Date: 2006-04-10 14:57

Message:
Logged In: YES 
user_id=1276121

see patch #1467770

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:50

Message:
Logged In: YES 
user_id=1488657

> Simply list operations such as remove() and append() are
> thread safe,

OK, my apologies... I did not know.

I did some more tests. On Linux, I found lots of:

  File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
  File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

The try...except solution does not handle this (since we are
in the "posix" section).

In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.

I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.



--

Comment By: Peter Åstrand (astrand)
Date: 2006-03-29 05:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-28 23:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 08:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

--

Comment By: cheops (atila-cheops)
Date: 2006-01-25 07:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotected.

try:
 list.remove(x)
except:
 pass

I have worked with 2.4.0, 2.4.1 and 2.4.2 and all three
needed the patch.
Hope this helps.

--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-23 16:34

Message:
Logged In: YES 
user_id=1434251

BTW: In my case, I call python.exe from a Windows service.

--

[ python-Bugs-1468231 ] test_grp test_pwd fail on Linux

[SourceForge.net]

Bugs item #1468231, was opened at 2006-04-11 08:29
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468231&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.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_grp test_pwd fail on Linux

Initial Comment:
Python 2.5a1, SUSE Linux
test_grp test_pwd fails when running "make test"

--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 10:18

Message:
Logged In: YES 
user_id=21627

This is a duplicate of #1465646.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2006-04-11 08:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 07:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 06:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

--

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

--

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "", line 1, in 
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

---
assert 1, ([s for s in x] +
   [s for s in x])
pass
---

--

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

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think all the others
mentioned so far have been fixed:

 * Raymond's warnings in compile.c (unused locals are fixed)
 * EXTENDED_ARG problem
 * LOAD_CONST/POP_TOP (note we can fix this in the optimizer
generally which would get rid of other useless code too)


--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-23 04:53

Message:
Logged In: YES 
user_id=80475

[ python-Bugs-1465408 ] HP-UX11i installation failure

[SourceForge.net]

Bugs item #1465408, was opened at 2006-04-06 01:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465408&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.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: HP-UX11i installation failure

Initial Comment:
% uname -a
HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user
license

% cc -V
cc: HP aC++/ANSI C B3910B A.06.07 [Feb 2 2006]

env CC=cc CXX=aCC ./configure
--prefix=/var/tmp/rwgk/py25a1 --without-gcc
make

The output of make ends with:

  No such file or directory: python
  *** Error exit code 127

  Stop.

I'll upload the full output of configure and make.

Note that the testdrive machine is publically accessible:

http://www.testdrive.hp.com/
telnet td176.testdrive.hp.com


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 11:26

Message:
Logged In: YES 
user_id=21627

The welease script should check that the exported time
stamps are already in the right sequence (i.e.
Python-ast.[ch] newer than their dependencies). If this is
not the case, a commit should be forced on the file that is
too old. Then, if the files don't change before the next
release, no time stamp changing will be necessary.

--

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2006-04-06 18:16

Message:
Logged In: YES 
user_id=71407

I get a complete build if I

touch Include/Python-ast.h Python/Python-ast.c

before running configure. If you wait a second after the svn
export and then touch these two files I'd expect the tarball
to work out of the box.

Another idea is to work with MD5 signatures, like SCons
does. But if you don't have a Python yet it is probably
difficult to find a fully portable solution.


--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-06 09:56

Message:
Logged In: YES 
user_id=29957

Right. Python.asdl and the output files that depend on it
have the same timestamps in the tarball. This is because
they get updated and all checked in in the same svn
revision. When the export is done, the timestamps are set to
the same time. 

Possible solutions:
  - make ignores this failure. Bad, because it might stop
_real_ errors.
  - make catches lack of Python, and skips the step. Ugly,
and hard to do in a platform-compatible way.
  - I change the 'welease.py' script to adjust the
timestamps of the files before making the release tarballs.
 This is so nasty it makes me sick. But I can't see a better
option. 


--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-04-06 09:48

Message:
Logged In: YES 
user_id=29957



If you put a '-' at the start of the line in the Makefile,
it should build ok. Make it:

$(AST_H) $(AST_C): $(AST_ASDL) $(ASDLGEN_FILES)
-$(ASDLGEN) $(AST_ASDL)

Obviously there's some issues with timestamps on the files
and it's trying to rebuild the file unnecessarily...


--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 11:08
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: AST
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Jeremy Hylton (jhylton)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Michael Hudson (mwh)
Date: 2006-04-11 10:41

Message:
Logged In: YES 
user_id=6656

Good morning Armin!

I've reported that bug already: http://python.org/sf/1441486
There's a patch which purports to fix it: http://python.org/sf/1446922
but I haven't gotten around to testing it.

(this is running the pypy/module/array tests or something, isn't it?)

--

Comment By: Armin Rigo (arigo)
Date: 2006-04-11 09:45

Message:
Logged In: YES 
user_id=4771

Another one: the literal -2147483648 (i.e. the value of
-sys.maxint-1) gives a long in 2.5, but an int in <= 2.4.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-03 08:30

Message:
Logged In: YES 
user_id=33168

The tuple store problem is fixed.  The only outstanding item
is the LOAD_CONST/POP_TOP.  I will fix that soon.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-02-18 06:56

Message:
Logged In: YES 
user_id=33168

Jeremy, there's no need to read anything before my last
comment at 2005-12-17 23:10.  The last two by Armin,
Michael, then my last comment are the only important ones. 
Everything that occurred before my 2005-12-17 comment was
taken care of AFAIK.

--

Comment By: Armin Rigo (arigo)
Date: 2006-02-12 21:54

Message:
Logged In: YES 
user_id=4771

Subscripting is generally a bit sloppy: e.g. the AST model has
no way to distinguish between a single value and a one-element
tuple value!  See:

>>> d = {}
>>> d[1,] = 6
>>> d
{1: 6}# !

I suggest we fix the model to turn the 'subs' of the 'Subscript' node
from a list of nodes to a single, mandatory 'sub' node.  If tupling is
necessary, it can be explicitly represented with a 'sub' containing a
'Tuple' node.

--

Comment By: Michael Hudson (mwh)
Date: 2006-02-09 15:02

Message:
Logged In: YES 
user_id=6656

We found another one.  Something is wrong in the compilation of augmented 
assignment to subscriptions containing tuples; running this code:

class C:
def __setitem__(self, i, v):
print i, v
def __getitem__(self, i):
print i
return 0

c = C()
c[4,5] += 1

gives a spurious exception:

Traceback (most recent call last):
  File "", line 1, in 
TypeError: object does not support item assignment

By contrast, "c[(4,5)] += 1" works fine.



--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-18 07:10

Message:
Logged In: YES 
user_id=33168

EXTENDED_ARG problem was fixed a while ago.
The assert/pass problem was fixed with: 41756.

That leaves the LOAD_CONST/POP_TOP optimization that was
lost and one compiler warning: marshal_write_mod() not being
used.

--

Comment By: Michael Hudson (mwh)
Date: 2005-12-11 00:41

Message:
Logged In: YES 
user_id=6656

You have to include those lines in a source file.  It still crashes for me.

--

Comment By: Brett Cannon (bcannon)
Date: 2005-12-10 23:44

Message:
Logged In: YES 
user_id=357491

I just checked Armin's problem code on rev. 41638 and it
worked for me in the interpreter.  You still having
problems, Armin?

--

Comment By: Armin Rigo (arigo)
Date: 2005-12-04 10:30

Message:
Logged In: YES 
user_id=4771

At rev 41584, the following code snippet triggers an assert
if --with-pydebug is enabled:
Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed

---
assert 1, ([s for s in x] +
   [s for s in x])
pass
---

--

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

Message:
Logged In: YES 
user_id=33168

Checkpoint of outstanding issues.  I think

[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi

[SourceForge.net]

Bugs item #146, was opened at 2006-04-04 21:42
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&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: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Thomas Heller (theller)
Summary: ctypes should be able to link with installed libffi

Initial Comment:
ctypes always uses the included libffi implementation
(which should be updated to current GCC HEAD). Pleae
add an option to build and link against a libffi, which
is installed on the system.

attached is a hack to just always build using the
installed libffi. I'm unsure how to find the correct
ffi implementation (maybe check for LIBFFI_H defined in
the ffi header?), and where to implement this check
(configure.ac --with-system-ffi=/usr?).


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 13:13

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as r45278.

--

Comment By: Matthias Klose (doko)
Date: 2006-04-10 22:45

Message:
Logged In: YES 
user_id=60903

documentation added.


--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-10 14:00

Message:
Logged In: YES 
user_id=21627

The code is fine, but it lacks documentation. There should
be some way to learn about --with-system-ffi, preferably by
either reading ./configure --help output, or reading README.

--

Comment By: Matthias Klose (doko)
Date: 2006-04-10 12:44

Message:
Logged In: YES 
user_id=60903

Setup.local has the disadvantage that you have to edit the
file. I updated the patch to only have an effect, if
configure is passed --with-system-ffi.


--

Comment By: Thomas Heller (theller)
Date: 2006-04-07 19:49

Message:
Logged In: YES 
user_id=11105

I'm astonished how flexible the build-system is :-), once
you leave Windows.

setup.py needs a change, though, so that the _ctypes/libffi
configure script is not run when not needed.

One possible advange of Modules/Setup.local is that one can
define additional compilation flags for ctypes - for
example, if ctypes would support it, to enable/disable
certain features (varargs function calls, for example).

--

Comment By: Martin v. Löwis (loewis)
Date: 2006-04-06 23:46

Message:
Logged In: YES 
user_id=21627

If this configuration needs an operator decision, I think
this decision is best made in Modules/Setup.local. Anybody
who wants to use the local libffi installation can do so, by
writing a Setup.local that lists the source files, and gives
-lffi as a library option. Setup.dist could provide a
commented version of such a configuration.

setup.py *should* then skip over building _ctypes, as it
should find out that _ctypes was already built through Makefile.

--

Comment By: Thomas Heller (theller)
Date: 2006-04-06 22:02

Message:
Logged In: YES 
user_id=11105

I do not really know.  Maybe using
distutils.sysconfig.get_config_var() ?

A pragmatic approach would be to parse pyconfig.h itself in
the setup script.

--

Comment By: Matthias Klose (doko)
Date: 2006-04-06 21:45

Message:
Logged In: YES 
user_id=60903

maybe a configure switch --with-system-ffi could do it?
How to pass this to the setup.py file?


--

Comment By: Thomas Heller (theller)
Date: 2006-04-06 21:17

Message:
Logged In: YES 
user_id=11105

I tried your patch on an AMD64 ubuntu 5.10, after I
installed the 4.0.1-4ubuntu9 libffi package.  It crashes in
ctypes/test/test_python_api.py, test_PyOS_snprintf.  IIRC,
libffi did not support varargs functions, but Andreas Degert
added support for them (for x86_64), and it works fine.

Ok, new features in libffi might not be the norm, but I see
no way how I can check whether a system-installed libffi
supports this feature or not.

Do *you* see a solution for that?

For the actual changes to setup.py, if the patch really is a
good idea:  Since I don't even know what a convience library
is I'll trust you fully that your patch does the right thing.

--

Comment By: Matthias Klose (doko)
Date: 2006-04-06 15:12

Message:
Logged In: YES 
user_id=60903

> do any of the buildbo

[ python-Bugs-1466301 ] ImportError: Module _subprocess not found

[SourceForge.net]

Bugs item #1466301, was opened at 2006-04-07 14:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466301&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: 3rd Party
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Africanis (africanis)
Assigned to: Nobody/Anonymous (nobody)
Summary: ImportError: Module _subprocess not found

Initial Comment:
I'm using Enthought Python 2.3.5 together with IPython 
and matplotlib on Windows XP SP2. I had problems 
importing pylab (in order actually to use matplotlib) 
until I changed the attached file (see from line 365). 

I have absolutely no idea what effect this will have 
on other modules (I'm fairly new to programming), but 
matplotlib seems to work okay now. Ignorance is 
bliss...


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-04-11 13:21

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. I'm not quite sure what you have been
doing: Python 2.3.5 did not include the subprocess module at
all. So if you got it either from IPython or from Enthought
Python, you could report the problem to them. They should
either include _subprocess.pyd (as it was released with
Python 2.4), or enable the if 0 block, meant for pywin32, or
drop subprocess entirely.

In any case, this should be a problem for Python 2.4 or (the
upcoming) Python 2.5. Closing it as a third-party bug.

--

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

[ python-Bugs-1465834 ] bdist_wininst preinstall script support is broken in 2.5a1

[SourceForge.net]

Bugs item #1465834, was opened at 2006-04-06 18:40
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465834&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: Distutils
Group: Python 2.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: Paul Moore (pmoore)
Assigned to: Nobody/Anonymous (nobody)
Summary: bdist_wininst preinstall script support is broken in 2.5a1

Initial Comment:
The attached zip file contains a trivial module. Run
"run_setup.bat" to create a bdist_wininst installer
(you'll need to edit it to make the preinstall script
path match where you unzipped the file).

The resulting installer fails with an error "Running the
pre-installation script failed".

--

>Comment By: Thomas Heller (theller)
Date: 2006-04-11 19:19

Message:
Logged In: YES 
user_id=11105

These apis are now macros, they were exported functions in
Python 2.4:

PyParser_SimpleParseFile
PyParser_SimpleParseString
PyRun_AnyFile
PyRun_AnyFileEx
PyRun_AnyFileFlags
PyRun_File
PyRun_FileEx
PyRun_FileFlags
PyRun_InteractiveLoop
PyRun_InteractiveOne
PyRun_SimpleFile
PyRun_SimpleFileEx
PyRun_SimpleString
PyRun_String
Py_CompileString

All of them, to be safe, should probably exposed as exported
functions again.

See also this thread on python-dev:

http://mail.python.org/pipermail/python-dev/2006-January/059374.html

Raising the priority to 7 because this must be fixed before
release.

--

Comment By: Paul Moore (pmoore)
Date: 2006-04-06 22:01

Message:
Logged In: YES 
user_id=113328

Seems to be limited to installers with preinstall scripts,
as far as I can tell. The main example is pywin32, which is
irritatingly significant :-)

(One oddness I couldn't check is that scripts don't seem to
get compiled any more - don't know if this is related to the
same issue. It's not a big deal either way, though).

The fix sounds reasonable.

--

Comment By: Thomas Heller (theller)
Date: 2006-04-06 20:22

Message:
Logged In: YES 
user_id=11105

bdist_wininst7.1.exe uses runtime dynamic linking to the
python dll.  Python25.dll doesn't export a
PyRun_SimpleString function anymore, it has been replaced by
a macro:
#define PyRun_SimpleString(s) PyRun_SimpleStringFlags(s, NULL)

bdist_wininst *could* be changed to use
PyRun_SimpleStringFlags instead, however, installers built
with previous versions of Python will then refuse to install
pure distributions to Python 2.5.

I have not checked if installers that do *not* have a
pre-install script will work or not.

I suggest to make PyRun_SimpleString an exported function
again - this should be cheap.

--

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

[ python-Bugs-1468727 ] Possible Integer overflow

[SourceForge.net]

Bugs item #1468727, was opened at 2006-04-11 18:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&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.5
Status: Open
Resolution: None
Priority: 5
Submitted By: ekellinis (ekellinis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible Integer overflow

Initial Comment:
There is possible integer overlow in the fcntlmodule.c 


=
fcntl_fcntl(PyObject *self, PyObject *args)
{
int fd;
int code;
int arg;
int ret;
char *str;
Py_ssize_t len;
char buf[1024];

if (PyArg_ParseTuple(args, "O&is#:fcntl",
 conv_descriptor, &fd,
&code, &str, &len)) {
if (len > sizeof buf) {
PyErr_SetString(PyExc_ValueError,
"fcntl string arg too long");
return NULL;
}
memcpy(buf, str, len);
=
Explanation : 
if "len" receives very large value (>integer) there is
a possiblity that it will become negative and the value
will bypass the if statement and go directly to
memcpy(buf, str, len);

The latest  revision of the module (42787) has int
replaced with Py_ssize_t which as it mentions at
http://www.python.org/dev/peps/pep-0353/
"...Py_ssize_t is introduced, which has the same size
as the compiler's size_t type, but is signed.." so the
problem seem to still be there.

-The int type is used from revision 42093 and back

Someone needs to be able to execute arbitrary python to
exploit it , possible effect  : break from the Python
sandbox



--

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

[ python-Bugs-1468727 ] Possible Integer overflow

[SourceForge.net]

Bugs item #1468727, was opened at 2006-04-11 18:00
Message generated for change (Settings changed) made by ekellinis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1468727&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.5
Status: Open
Resolution: None
>Priority: 7
Submitted By: ekellinis (ekellinis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible Integer overflow

Initial Comment:
There is possible integer overlow in the fcntlmodule.c 


=
fcntl_fcntl(PyObject *self, PyObject *args)
{
int fd;
int code;
int arg;
int ret;
char *str;
Py_ssize_t len;
char buf[1024];

if (PyArg_ParseTuple(args, "O&is#:fcntl",
 conv_descriptor, &fd,
&code, &str, &len)) {
if (len > sizeof buf) {
PyErr_SetString(PyExc_ValueError,
"fcntl string arg too long");
return NULL;
}
memcpy(buf, str, len);
=
Explanation : 
if "len" receives very large value (>integer) there is
a possiblity that it will become negative and the value
will bypass the if statement and go directly to
memcpy(buf, str, len);

The latest  revision of the module (42787) has int
replaced with Py_ssize_t which as it mentions at
http://www.python.org/dev/peps/pep-0353/
"...Py_ssize_t is introduced, which has the same size
as the compiler's size_t type, but is signed.." so the
problem seem to still be there.

-The int type is used from revision 42093 and back

Someone needs to be able to execute arbitrary python to
exploit it , possible effect  : break from the Python
sandbox



--

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

[ python-Bugs-1199282 ] subprocess _active.remove(self) self not in list _active

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: cheops (atila-cheops)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess _active.remove(self) self not in list _active

Initial Comment:
I start a subprocess in a seperate thread (25 concurrent 
threads)
in some of the threads the following error occurs
 
Exception in thread Thread-4:
Traceback (most recent call last):
  File "C:\Python24\lib\threading.py", line 442, in 
__bootstrap
self.run()
  File "upgrade.py", line 45, in run
returncode = p.wait()
  File "C:\Python24\lib\subprocess.py", line 765, in wait
_active.remove(self)
ValueError: list.remove(x): x not in list
 
this is the code that starts the subprocess and where I 
wait for the result
 
p = subprocess.Popen('command', \
 stdin=None, 
stdout=subprocess.PIPE, \
 stderr=subprocess.STDOUT, 
universal_newlines=True)
returncode = p.wait()
errormessage = p.stdout.readlines()

--

>Comment By: cheops (atila-cheops)
Date: 2006-04-11 20:10

Message:
Logged In: YES 
user_id=1276121

there are 2 definitions of the function poll, one for 
windows and one for POSIX systems
in the windows version _deadlock is not used
in the POSIX version _deadlock is used

see also modification made by loewis in committed version 
45234

--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-04-11 07:21

Message:
Logged In: YES 
user_id=1434251

I looked at the patch #1467770 you mentioned and 
downloaded the patch.

Is it correct that _deadlock variable is used in the 
definition of poll but it is not in the argument list?


--

Comment By: cheops (atila-cheops)
Date: 2006-04-10 14:57

Message:
Logged In: YES 
user_id=1276121

see patch #1467770

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-29 13:50

Message:
Logged In: YES 
user_id=1488657

> Simply list operations such as remove() and append() are
> thread safe,

OK, my apologies... I did not know.

I did some more tests. On Linux, I found lots of:

  File "./subprocess.py", line 428, in call
return Popen(*args, **kwargs).wait()
  File "./subprocess.py", line 1023, in wait
pid, sts = os.waitpid(self.pid, 0)
OSError: [Errno 10] No child processes

The try...except solution does not handle this (since we are
in the "posix" section).

In my opinion, the call to _cleanup() in Popen.__init__() is
useless (it just checks if older processes have stopped when
a new one is started. I cannot see why it could be
mandatory) and it is the root of this bug.

I commented it out (line 506) and retried my tests on Linux
& Windows plateforms: I had no exception at all.



--

Comment By: Peter Åstrand (astrand)
Date: 2006-03-29 05:11

Message:
Logged In: YES 
user_id=344921

>I think accesses to _active should be serialized in a
>thread-safe way. _active could be a Queue (from the Queue
>module) for example

Simply list operations such as remove() and append() are
thread safe, so there should be no need for a Queue. Also, a
Queue cannot be used since the subprocess module needs to be
compatible with Python 2.2. 

--

Comment By: Tristan Faujour (tfaujour)
Date: 2006-03-28 23:17

Message:
Logged In: YES 
user_id=1488657

I am running into the same problem on a Windows 2k/XP
plateform with a multi-threaded application. It occurs randomly.

It has never appened (yet) on a Linux plateform.

I think accesses to _active should be serialized in a
thread-safe way. _active could be a Queue (from the Queue
module) for example.


--

Comment By: HVB bei TUP (hvb_tup)
Date: 2006-01-25 08:10

Message:
Logged In: YES 
user_id=1434251

Wouldn't it be best to completely remove any references 
to "_active" and "_cleanup"?

--

Comment By: cheops (atila-cheops)
Date: 2006-01-25 07:08

Message:
Logged In: YES 
user_id=1276121

As suggested by astrand
adding a try ... except clause in the file subprocess.py did
the job
I had to add that try ... except clause in 2 places
if you look in the file there are 2 instances were
list.remove(x) occurs unprotecte

[ python-Bugs-1463840 ] logging.StreamHandler ignores argument if it compares False

[SourceForge.net]

Bugs item #1463840, was opened at 2006-04-03 21:37
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463840&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Winkler (slinkp)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.StreamHandler ignores argument if it compares False

Initial Comment:
The docs at http://docs.python.org/lib/node346.html say
this:
"""
class StreamHandler([strm])
Returns a new instance of the StreamHandler class.
If strm is specified, the instance will use it for
logging output; otherwise, sys.stderr will be used.
"""

However, that's not quite true.
StreamHandler.__init__() actually tests for truth of
strm, which means you have to be careful that strm does
not happen to evaluate to boolean false.

My use case: I'm writing some tests that verify that
certain methods put certain strings into the logs. So
my setUp() adds a StreamHandler with its stream set to
an instance of this trivial class:

class FakeLog(list):
def write(self, msg):
self.append(msg)
def flush(self):
pass

... which does not work, because an empty list
evaluates to false, so my handler writes to stderr even
though i told it not to.  It's trivial to work around
this by adding a __nonzero__ method, but the need to do
so is certainly not clear from the docs. Therefore imho
this is a bug. The patch is trivial, and is attached.

--

>Comment By: Vinay Sajip (vsajip)
Date: 2006-04-11 21:45

Message:
Logged In: YES 
user_id=308438

Fix checked into Subversion.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 06:20

Message:
Logged In: YES 
user_id=33168

Vinay, any comments?  We are preparing for 2.5 alpha1 within
a day.  There will be freeze real soon now.

--

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

[ python-Bugs-1466641 ] Bogus SyntaxError in listcomp

[SourceForge.net]

Bugs item #1466641, was opened at 2006-04-08 00:51
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1466641&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.5
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Thomas Wouters (twouters)
Summary: Bogus SyntaxError in listcomp

Initial Comment:
The attached syn.py gives a SyntaxError in 2.5a1 and
trunk.  Works fine in earlier Pythons.  Whittled down
from real-life Zope3 source.

def d(dir):
return [fn
for fn in os.listdir(dir)
if fn
if fn]


--

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-12 02:08

Message:
Logged In: YES 
user_id=34209

Fixed in trunk, revision 45286.

--

Comment By: Thomas Wouters (twouters)
Date: 2006-04-10 02:43

Message:
Logged In: YES 
user_id=34209

Yeah, this is definately caused by the PEP 308 patch, so I
guess the error is mine (but don't tell anyone.) Unless
someone beats me to it, I'll fix it and add a test tomorrow
(but please don't fix it without checking in some tests.)


--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-09 16:57

Message:
Logged In: YES 
user_id=849994

Changing

list_if: 'if' test [list_iter]

to

list_if: 'if' old_test [list_iter]

solves the problem. Conditionals must then be enclosed in
parens.

Generator expressions are also affected.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-09 16:50

Message:
Logged In: YES 
user_id=849994

Haha. The second "if" is seen as the beginning of a
conditional expression, so

return [fn for fn in os.listdir(dir) if fn if fn else fn]

works.

--

Comment By: Tim Peters (tim_one)
Date: 2006-04-09 06:07

Message:
Logged In: YES 
user_id=31435

The whittled-down version looks ridiculous, but the original
wasn't quite such an affront to beauty :-)  It's really no
stranger than allowing pure "if" statements to nest, and it
would be more painful to contort the grammar to disallow it
(I haven't looked at the 2.5 parser, but it was very
surprising to me that it didn't allow it!).

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2006-04-09 05:32

Message:
Logged In: YES 
user_id=1038590

Is including two if clauses with a single for clause really
meant to be legal?

*goes and looks at language reference*

Wow. What a strange way to write "and". . .

--

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