[issue2320] Race condition in subprocess using stdin

Adam Olsen <[EMAIL PROTECTED]> added the comment: This is messy. File descriptors from other threads are leaking into child processes, and if the write end of a pipe never gets closed in all of them the read end won't get EOF. I suspect "cat"'s stdin is getting duplicated like that, but I haven

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Tony Wallace <[EMAIL PROTECTED]> added the comment: > how do you know Here is the story, sorry I skipped it before- I was at work then. I was doing the basic build-from-source on RHEL (Centos) Linux, because I don't have root and I need to install it in $HOME/something. I don't try to change

[issue3104] overzealous garbage collector (dict)

Paul Melis <[EMAIL PROTECTED]> added the comment: The script is still not a test case, as it doesn't *demonstrate* the problem when run. You need to provide more information for this to be reproducable by others. - what exact input did you use? (e.g. include the IRC log file on which you claim

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Are you by any chance using gcc 4.3? That compiler is known to miscompile Python, see issue3019 or issue2626. Also, I'm puzzled that your prompt says Python-2.5.1 when configuring with a prefix suggesting 2.5.2.

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Tony Wallace <[EMAIL PROTECTED]> added the comment: > are you using gcc 4.3 No, I don't think so. [EMAIL PROTECTED] tony]$ gcc --version gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-53) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying condition

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Are you willing to debug this? Otherwise, I'll have to close this as "works-for-me" (which it does, as it did for many other people). ___ Python tracker <[EMAIL PROTECTED]>

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Tony Wallace <[EMAIL PROTECTED]> added the comment: > are you willing Yes, so long as I don't need root, I can follow instructions OK. By the way, the same thing (memory leak 2.5.2) occurred on Centos 4.6, a different Linux box. Lets proceed on that Centos 4.6 box. Here are the particulars: Py

[issue3107] memory leak in make test (in "test list"), 2.5.2 not 2.5.1, Linux 64bit

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Run "python Lib/test/test_lists.py" separately, and find out which specific test fails (to complete). Report that, and also try to separate that test's code into its own file, and see whether you can reproduce it there. If so, try to further

[issue3104] overzealous garbage collector (dict)

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > The original text file was an IRC log. Shoving Charles Dickens' "Great > Expectations" 17 times in a text file and then parsing it doesn't show > this problem for some weird reason. I'd say the "weird reason" is probably a bug in your scrip

[issue2650] re.escape should not escape underscore

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Talking about performance, why use a loop to escape special characters when you could use a regular expression to escape them all at once? -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]>

[issue3088] test_multiprocessing hangs on OS X 10.5.3

roudkerk <[EMAIL PROTECTED]> added the comment: I suspect the problems with WithManagerTestCondition.notify_all() may have to do with the thread safety of the proxies. If you replace Thread(...) by self.Process(...) in that test then the problem may go away.

[issue3088] test_multiprocessing hangs on OS X 10.5.3

Changes by Adam Olsen <[EMAIL PROTECTED]>: -- nosy: +Rhamphoryncus ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list maili

[issue3109] test_multiprocessing seems fragile

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- nosy: +roudkerk ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3109] test_multiprocessing seems fragile

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- assignee: -> jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list ma

[issue3100] weakref subclass segfault

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- nosy: +roudkerk ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3110] Multiprocessing package build problem on Solaris 10

New submission from Jesse Noller <[EMAIL PROTECTED]>: Per skip's email: FWIW, it appears that Solaris doesn't define SEM_VALUE_MAX but does define _SEM_VALUE_MAX in sys/params.h. .../Modules/_multiprocessing/multiprocessing.c: In function 'init_multiprocessing': .../Modules/_multiprocess

[issue3111] multiprocessing pkg Debian compilation error

New submission from Jesse Noller <[EMAIL PROTECTED]>: Both debian ia64 and PPC are failing the mp test suite with the following error: Re-running test 'test_multiprocessing' in verbose mode test test_multiprocessing crashed -- : [Errno 38] Function not implemented Traceback (most recent call l

[issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- title: multiprocessing pkg Debian compilation error -> multiprocessing ppc Debian/ ia64 Ubuntu compilation error ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3111] multiprocessing ppc Debian/ ia64 Ubuntu compilation error

Jesse Noller <[EMAIL PROTECTED]> added the comment: Sorry, should have been debian PPC and ubuntu ia64 ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3108] Implicit exception chaining (PEP 3134)

Guido van Rossum <[EMAIL PROTECTED]> added the comment: Submitted as r64281. We still need a doc patch and changes to the exception printing (perhaps also to traceback.py). Please open new issues for those. -- resolution: -> fixed status: open -> closed __

[issue3112] implement PEP 3134 exception reporting

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: Traceback reporting needs to be altered to support exception chaining as per PEP 3134. -- components: Interpreter Core messages: 68214 nosy: benjamin.peterson priority: critical severity: normal status: open title: implement PEP

[issue3113] Document exception chaining

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: PEP 3134's features need to be documented. -- assignee: georg.brandl components: Documentation messages: 68215 nosy: benjamin.peterson, georg.brandl priority: high severity: normal status: open title: Document exception chaining

[issue3112] implement PEP 3134 exception reporting

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- versions: +Python 3.0 -Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Py

[issue3108] Implicit exception chaining (PEP 3134)

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: See #3112 and #3113. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3112] implement PEP 3134 exception reporting

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3113] Document exception chaining

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing

[issue3112] implement PEP 3134 exception reporting

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Thinking about this, I realized that an exception can become its own context if it is explicitly re-raised in its except handler (with "raise variable", not bare "raise"). Not a critical bug, but it should be fixed in order to avoid delayed ga

[issue3114] bus error on lib2to3

New submission from Benjamin Peterson <[EMAIL PROTECTED]>: I was just merging 2to3 work (and you'll have to do svnmerge.py merge in Lib/lib2to3 for this to work) into py3k and was running the tests when this rather alarming thing happended: $ ./python.exe Lib/test/regrtest.py test_lib2to3 ... te

[issue3109] test_multiprocessing seems fragile

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Apparently the error can happen in test_pickling: test_pickling (__main__.WithProcessesTestPicklingConnections) ... Process Process-24: Traceback (most recent call last): File "/home/antoine/py3k/traceback/Lib/multiprocessing/process.py", l

[issue3109] test_multiprocessing seems fragile

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Oh, in another regrtest run, test_multiprocessing just hanged without eating any CPU, this is what it printed after I pressed Ctrl-C: test_multiprocessing Process PoolWorker-5:4: Traceback (most recent call last): File "/home/antoine/py3k/t

[issue3114] bus error on lib2to3

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I have determined that this was caused by r64121. -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3114] bus error on lib2to3

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: I should mention the Bus error happens at test_future_builtins (lib2to3.tests.test_fixers.Test_filter). ___ Python tracker <[EMAIL PROTECTED]> _

[issue3115] os.listdir randomly fails on occasions when it shouldn't

New submission from philipspencer <[EMAIL PROTECTED]>: Python's os.listdir function has the following code in Modules/posixmodule.c: errno = 0 ... for (;;) { Py_BEGIN_ALLOW_THREADS ep = readdir(dirp); Py_END_ALLOW_THREADS if (ep == NULL)

[issue3114] bus error on lib2to3

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: The following patch fixes it, which is somehow a bit scary... -- keywords: +patch Added file: http://bugs.python.org/file10629/3114.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue3114] bus error on lib2to3

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: And a test. Added file: http://bugs.python.org/file10630/test_3114.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue3114] bus error on lib2to3

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Thanks very much. Committed in r64384. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> _

[issue3114] bus error on lib2to3

Adam Olsen <[EMAIL PROTECTED]> added the comment: I'm not sure that fix is 100% right - it fixes safety, but not correctness. Wouldn't it be more correct to move all 3 into temporaries, assign from tstate, then XDECREF the temporaries? Otherwise you're going to expose just the value or tracebac

[issue2475] Popen.poll always returns None

Mike Lisanke <[EMAIL PROTECTED]> added the comment: Isn't this a critical problem. The .poll() function serves as a means to check the status of the process started. When it continues to report 'None' to a process which has already terminated, it creates a false positive of a hung process. Dealin

[issue3114] bus error on lib2to3

Guido van Rossum <[EMAIL PROTECTED]> added the comment: N.B. Benjamin made a typo in the revision, it's r64284. -- nosy: +gvanrossum resolution: fixed -> status: closed -> open ___ Python tracker <[EMAIL PROTECTED]>