[issue13679] Multiprocessing system crash

Rock Achu added the comment: Alright. Just running: import multiprocessing thread = multiprocessing.Process() thread.start() raw_input() - Causes the crash. This time there is no output, so it is essentailly invisible. Caught me by surprise. --

[issue13679] Multiprocessing system crash

Rock Achu added the comment: Alright. The issue stays here. Passing nothing to multiprocessing.Process still reproduces the issue. someone else know how to deal with this? -- ___ Python tracker

[issue13679] Multiprocessing system crash

Rock Achu added the comment: Changing the function name and removing the argument (self) passed to func doesn't change a thing. -- ___ Python tracker ___ _

[issue13679] Multiprocessing system crash

Rock Achu added the comment: More clues: the function _M_Process.func isn't being called. -- ___ Python tracker ___ ___ Pytho

[issue13679] Multiprocessing system crash

Rock Achu added the comment: By inserting print statements and feverishly killing the process, I narrowed it down to the statement: self.thread.start() that causes the issue. which runs _M_Process.func() in a multiprocessing.Process -- ___ Python tr

[issue13679] Multiprocessing system crash

Rock Achu added the comment: Ok, using other code, I narrowed it down to this code and before: for i in xrange(10): spawner.newproc(run=True) repeating infinitely which only should set a variable (self.busy) to false -- ___ Python tracker

[issue13679] Multiprocessing system crash

Rock Achu added the comment: Or did I only have 20 threads? if the program was running in a loop, then it would have spawned 20 threads each, leading to the huge amount of processes, and probably the other issues. So why does it run so many times? --

[issue13679] Multiprocessing system crash

Rock Achu added the comment: On a hunch opened task manager. There were over 9000 python processes open. Shocking. That was probably the cause of the system freeze. However I only had 20 threads open. Why so many processes? -- ___ Python tracker

[issue13679] Multiprocessing system crash

Rock Achu added the comment: I hit Ctrl-C right after opening the bat file and got this mess: -- Added file: http://bugs.python.org/file24109/error.txt ___ Python tracker ___ __

[issue13679] Multiprocessing system crash

New submission from Rock Achu : running this script repeatedly causes corruption in the console window. Just before posting this report, it led to a complete windows system freeze. running python 2.7 x86 on windows x64. The programs seems to run a couple times (when it is supposed to run once

[issue13645] import machinery vulnerable to timestamp collisions

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue13676] sqlite3: Zero byte truncates string contents

Antoine Pitrou added the comment: Where are the tests? :) -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue13674] crash in datetime.strftime

patrick vrijlandt added the comment: Is it relevant that 2.7.2 _does_ throw a correct exception? -- ___ Python tracker ___ ___ Python

[issue13673] PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called

sbt added the comment: > I think calling PyErr_WriteUnraisable would be more appropriate than > PyErr_Clear. You mean just adding PyErr_CheckSignals(); if (PyErr_Occurred()) PyErr_WriteUnraisable(NULL); before the call to PyFile_WriteString()? That seems to work: >>> from

[issue13678] way to prevent accidental variable overriding

Benjamin Peterson added the comment: I suggest you mail python-ideas. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue13645] import machinery vulnerable to timestamp collisions

Antoine Pitrou added the comment: Here is a patch adding the source code size to the pyc header. The number of places where details of the pyc file format are hard coded is surprisingly high... Unfortunately, I had to modify importlib's public API (path_mtime -> path_stats). I find it unfortun

[issue13678] way to prevent accidental variable overriding

James Hutchison added the comment: For starters, this would be most efficient implementation: def unique(varname, value, scope): assert(not varname in scope); scope[varname] = value; Usage: unique('b', 1, locals()); print(b); But you can't put that in a loop else it will false trigger

[issue7719] distutils: ignore .nfsXXXX files

Zbyszek Szmek added the comment: Review of both patches (python-2.5.1-distutils-aixnfs.patch and dir_util.py.diff) as they are essentially the same: I think that the test is in wrong place: we would want to ignore those .nfs* files always, not just when checking for symlinks. A separate test

[issue13678] way to prevent accidental variable overriding

Benjamin Peterson added the comment: I think this more the domain of pylint/pyflakes. -- nosy: +benjamin.peterson resolution: -> rejected status: open -> closed ___ Python tracker

[issue13678] way to prevent accidental variable overriding

Eric Snow added the comment: Interesting thought, the syntax seems unnecessary. Adding new syntax to the language is something that happens rarely and only with a _lot_ of consideration. As a slightly more verbose alternative, currently you can do this: def fail_if_defined(*args, namespa

[issue13674] crash in datetime.strftime

Tim Golden added the comment: Yes, but the MS crt strftime *for %y* requires a year >= 1900 (ie tm_year >= 0). Looks like we need a special check. -- ___ Python tracker ___ ___

[issue13678] way to prevent accidental variable overriding

New submission from James Hutchison : In python is currently there a way to elegantly throw an error if a variable is already in the current scope? For example: def longfunc(self, filename): FILE = open(filename); header = FILE.readline(); ... bunch of code ... childfiles = sel

[issue13674] crash in datetime.strftime

STINNER Victor added the comment: timemodule.c has the following check: #if defined(_MSC_VER) || defined(sun) if (buf.tm_year + 1900 < 1 || < buf.tm_year + 1900) { PyErr_SetString(PyExc_ValueError, "strftime() requires year in [1; ]"); return

[issue13673] PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called

Antoine Pitrou added the comment: I think calling PyErr_WriteUnraisable would be more appropriate than PyErr_Clear. I also wonder whether it's ok to ignore the exception. Pressing e.g. Ctrl-C generally shouldn't fail to stop the program, even if another exception is being processed at that mo

[issue13674] crash in datetime.strftime

Tim Golden added the comment: ... and that's because the tm struct defines the tm_year field as an offset from 1900. Sorry for the false start. I'll look at the MS runtime stuff instead -- ___ Python tracker

[issue13673] PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called

sbt added the comment: Attached is a patch for the default branch. Before calling PyFile_WriteString() the patch saves the current exception. Then it calls PyErr_CheckSignals() and clears the current exception if any. After calling PyFile_WriteString() the exception is restored. I am not s

[issue12715] Add symlink support to shutil functions

Antoine Pitrou added the comment: Patch is now applied to 3.3, thank you for your patience :) -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker _

[issue12715] Add symlink support to shutil functions

Roundup Robot added the comment: New changeset cf57ef65bcd0 by Antoine Pitrou in branch 'default': Issue #12715: Add an optional symlinks argument to shutil functions (copyfile, copymode, copystat, copy, copy2). http://hg.python.org/cpython/rev/cf57ef65bcd0 -- nosy: +python-dev __

[issue13677] correct docstring for builtin compile

New submission from Jim Jewett : The current docstring for compile suggests that the flags are strictly for selecting future statements. These are not the only flags. It also suggests that the source must be source code and the result will be bytecode, which isn't quite true. I suggest chang

[issue13675] IDLE won't open if it can't read recent-files.lst

Michael Foord added the comment: Thanks -- resolution: -> duplicate status: open -> closed ___ Python tracker ___ ___ Python-bugs-li

[issue13674] crash in datetime.strftime

Tim Golden added the comment: This is happening on Windows x86 against the current tip. The MS C runtime can handle older dates; it's just that we're taking 1900 off the year at some point. (At least, I think that's what's happening). FWIW you only need time.strftime to reproduce the error:

[issue13675] IDLE won't open if it can't read recent-files.lst

Roger Serwy added the comment: This is a duplicate of issue4625 and was fixed. The silently failing is part of issue13582. -- nosy: +serwy ___ Python tracker ___ __

[issue12715] Add symlink support to shutil functions

Antoine Pitrou added the comment: I've checked the latest patch to work fine under Windows 7 (and Linux, of course). -- stage: -> commit review ___ Python tracker ___

[issue9260] A finer grained import lock

Antoine Pitrou added the comment: > It owns the lock, but hasn't yet updated the lock's owner > (lock->tstate), so another thread calling detect_circularity() will > think that this lock is available, and will proceed, which can > eventually lead to a deadlock. That's true. Do you think temptat

[issue13673] PyTraceBack_Print() fails if signal received but PyErr_CheckSignals() not called

sbt added the comment: I think I have found the problem. PyTraceBack_Print() calls PyFile_WriteString(), which calls PyFile_WriteObject(), which calls PyObject_Str() which begins with PyObject_Str(PyObject *v) { PyObject *res; if (PyErr_CheckSignals()) return NULL;

[issue9260] A finer grained import lock

Charles-François Natali added the comment: IIUC, the deadlock avoidance code just checks that acquiring a per-module lock won't create a cycle. However, I think there's a race, because the cycle detection and the lock acquisition is not atomic. For example, let's say we have a thread exactly he

[issue13676] sqlite3: Zero byte truncates string contents

New submission from Petri Lehtinen : Inserting a string with embedded zero byte only inserts the string up to the first zero byte: import sqlite3 connection = sqlite3.connect(':memory:') cursor = connection.cursor() cursor.execute('CREATE TABLE test (value TEXT)') cursor.execute('INSERT INTO

[issue13673] SIGINT prevents raising of exceptions unless PyErr_CheckSignals() called

sbt added the comment: I have tried the same with Python 2.7.1 on Linux. The problem is the same, but one gets a partial traceback with no exception: >>> import sys, testsigint >>> testsigint.wait() ^CTraceback (most recent call last): File "", line 1, in >>> sys.last_value Ru

[issue13675] IDLE won't open if it can't read recent-files.lst

New submission from Michael Foord : Reported by a user. Reported on Windows but probably not Windows specific. If IDLE doesn't have permission to read the recent-files.lst file then it crashes. (When launched with pythonw.exe on Windows it silently fails to open with no error message to the us

[issue13674] crash in datetime.strftime

Changes by Florent Xicluna : -- nosy: +belopolsky, flox, haypo versions: +Python 3.3 ___ Python tracker ___ ___ Python-bugs-list maili

[issue12715] Add symlink support to shutil functions

Hynek Schlawack added the comment: Added new patch with protection for the remaining UF_NODUMPs in the test case. All raised issues should be fixed now. :) -- ___ Python tracker __

[issue12715] Add symlink support to shutil functions

Changes by Hynek Schlawack : Added file: http://bugs.python.org/file24102/8330f2045f4d.diff ___ Python tracker ___ ___ Python-bugs-list mailin

[issue13674] crash in datetime.strftime

maniram maniram added the comment: This bug can not be reproduced in Python 3.2.2 on Ubuntu. Since Python 2.7.2 on your system raises a ValueError for dates below 1900 ,your system's strftime probably does not allow dates below 1900 (unlike Ubuntu). Python 3.2.2's datetime.strftime should hand

[issue13671] double comma cant be parsed in config module

Łukasz Langa added the comment: Hello, Alexander. ConfigObj is an external library. It is not maintained by the core team. You can report your issue to the ConfigObj issue tracker here: http://code.google.com/p/configobj/issues/list -- components: +None -Regular Expressions resolution

[issue13674] crash in datetime.strftime

New submission from patrick vrijlandt : This causes a crash in python 3.2.2 and 3.2, but not in 2.7.2 C:\Python32>python Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime