Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multiprocessing.dummy craches when self._parent._children does not exist #59086

Closed
ItayBrandes mannequin opened this issue May 22, 2012 · 7 comments
Closed

multiprocessing.dummy craches when self._parent._children does not exist #59086

ItayBrandes mannequin opened this issue May 22, 2012 · 7 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ItayBrandes
Copy link
Mannequin

ItayBrandes mannequin commented May 22, 2012

BPO 14881
Nosy @terryjreedy

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-05-25.19:37:49.901>
created_at = <Date 2012-05-22.08:51:10.434>
labels = ['type-bug', 'library']
title = 'multiprocessing.dummy craches when self._parent._children does not exist'
updated_at = <Date 2013-10-19.00:33:25.312>
user = 'https://bugs.python.org/ItayBrandes'

bugs.python.org fields:

activity = <Date 2013-10-19.00:33:25.312>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2012-05-25.19:37:49.901>
closer = 'sbt'
components = ['Library (Lib)']
creation = <Date 2012-05-22.08:51:10.434>
creator = 'Itay.Brandes'
dependencies = []
files = []
hgrepos = []
issue_num = 14881
keywords = []
message_count = 7.0
messages = ['161339', '161576', '161592', '161610', '200302', '200337', '200338']
nosy_count = 5.0
nosy_names = ['terry.reedy', 'Andres.Riancho', 'python-dev', 'sbt', 'Itay.Brandes']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue14881'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

@ItayBrandes
Copy link
Mannequin Author

ItayBrandes mannequin commented May 22, 2012

multiprocessing.dummy crashes when attempting to create a ThreadPool from a Thread.

The following code will crush on 2.7.3:

    import multiprocessing.dummy
    import threading
     
    class Worker(threading.Thread):
        def __init__(self):
            threading.Thread.__init__(self)
     
        def run(self):
            poll = multiprocessing.dummy.Pool(5)
            print str(poll)
     
    w = Worker()
    w.start()

will crush with the following traceback:

    poll = multiprocessing.dummy.Pool(5)
  File "C:\Python27\lib\multiprocessing\dummy\__init__.py", line 150, in Pool
    return ThreadPool(processes, initializer, initargs)
  File "C:\Python27\lib\multiprocessing\pool.py", line 685, in __init__
    Pool.__init__(self, processes, initializer, initargs)
  File "C:\Python27\lib\multiprocessing\pool.py", line 136, in __init__
    self._repopulate_pool()
  File "C:\Python27\lib\multiprocessing\pool.py", line 199, in _repopulate_pool
    w.start()
  File "C:\Python27\lib\multiprocessing\dummy\__init__.py", line 73, in start
    self._parent._children[self] = None
AttributeError: 'Worker' object has no attribute '_children'

If you have access to the thread itself, you can set the _children attribute youself (w._children = weakref.WeakKeyDictionary()), but it is not possible with threads different from threading.thread (Such as PyQt4's QThread thread, which is essential for GUI programming).

The fix that I found is to edit the Python27\Lib\multiprocessing\dummy\init.py file. The crashing code is line number 73.
This line should be nested in an if block:

        if hasattr(self._parent, '_children'):
            self._parent._children[self] = None

That way the code is fixed.
Thanks!

@ItayBrandes ItayBrandes mannequin added type-crash A hard crash of the interpreter, possibly with a core dump stdlib Python modules in the Lib dir labels May 22, 2012
@python-dev
Copy link
Mannequin

python-dev mannequin commented May 25, 2012

New changeset 1f5d2642929a by Richard Oudkerk in branch '2.7':
Issue bpo-14881: Allow normal non-main thread to spawn a dummy process
http://hg.python.org/cpython/rev/1f5d2642929a

New changeset 0528ec18e230 by Richard Oudkerk in branch '3.2':
Issue bpo-14881: Allow normal non-main thread to spawn a dummy process
http://hg.python.org/cpython/rev/0528ec18e230

@terryjreedy
Copy link
Member

3.3 commit is http://hg.python.org/cpython/rev/9373ca8c6c55
Richard, it did not record here because you just said 'Merge' rather than "bpo-14881 merge" ;-).
Great to see a crasher fixed. Ready to close?

@sbt
Copy link
Mannequin

sbt mannequin commented May 25, 2012

I'll, remember that in future;-)

Closing.

@sbt sbt mannequin closed this as completed May 25, 2012
@sbt sbt mannequin added type-bug An unexpected behavior, bug, or error and removed type-crash A hard crash of the interpreter, possibly with a core dump labels May 25, 2012
@andresriancho
Copy link
Mannequin

andresriancho mannequin commented Oct 18, 2013

Is this a duplicate for http://bugs.python.org/issue10015
bpo-10015 ?

@terryjreedy
Copy link
Member

Since this is already fixed and closed, the question is more relevant to bpo-10015 and whether it should be closed. The answer seems to be yes.

@terryjreedy
Copy link
Member

By the way, thanks for noticing, so it *can* be closed.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant