This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2011年12月30日 04:39 by Rock.Achu, last changed 2022年04月11日 14:57 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| issue.zip | Rock.Achu, 2011年12月30日 04:39 | File that causes the problem | ||
| error.txt | Rock.Achu, 2011年12月30日 04:42 | Huge Traceback | ||
| Messages (14) | |||
|---|---|---|---|
| msg150355 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 04:39 | |
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), with the output becoming more and more corrupted.
One time it printed lots of triple quotes (""") and import os messages, even though none of those are in the script.
To reproduce run the spawner.test.bat file inside the zip.
Remember not to run with stuff you wont want to lose open.
|
|||
| msg150356 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 04:42 | |
I hit Ctrl-C right after opening the bat file and got this mess: |
|||
| msg150357 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 04:50 | |
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? |
|||
| msg150358 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 04:53 | |
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? |
|||
| msg150359 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:26 | |
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 |
|||
| msg150360 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:35 | |
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 |
|||
| msg150361 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:36 | |
More clues: the function _M_Process.func isn't being called. ???? |
|||
| msg150362 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:37 | |
Changing the function name and removing the argument (self) passed to func doesn't change a thing. |
|||
| msg150363 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:39 | |
Alright. The issue stays here. Passing nothing to multiprocessing.Process still reproduces the issue. someone else know how to deal with this? |
|||
| msg150364 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 05:58 | |
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. |
|||
| msg150370 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2011年12月30日 10:55 | |
Well, have you read http://docs.python.org/library/multiprocessing.html#windows ? (especially "Safe importing of main module") |
|||
| msg150384 - (view) | Author: Rock Achu (Rock.Achu) | Date: 2011年12月30日 18:03 | |
Erm.. No. I was unaware I had to do so. Next time I'll be more careful. Anyways, the docs say that python should throw a RuntimeError, but it didn't? And would it be doable to add a warning at the top of the multiprocessing tutorial/page that section? |
|||
| msg150386 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2011年12月30日 18:08 | |
> Anyways, the docs say that python should throw a RuntimeError, but it > didn't? I think running it directly would raise a RuntimeError, but importing it wouldn't. > And would it be doable to add a warning at the top of the > multiprocessing tutorial/page that section? In the introduction you have the following note, together with a link to the relevant section: "Functionality within this package requires that the __main__ module be importable by the children. This is covered in Programming guidelines however it is worth pointing out here." |
|||
| msg150387 - (view) | Author: Antoine Pitrou (pitrou) * (Python committer) | Date: 2011年12月30日 18:10 | |
Ok, closing this issue. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:57:25 | admin | set | github: 57888 |
| 2011年12月30日 18:10:01 | pitrou | set | status: open -> closed resolution: not a bug messages: + msg150387 |
| 2011年12月30日 18:08:06 | pitrou | set | messages: + msg150386 |
| 2011年12月30日 18:03:32 | Rock.Achu | set | messages: + msg150384 |
| 2011年12月30日 10:55:55 | pitrou | set | nosy:
+ pitrou messages: + msg150370 |
| 2011年12月30日 05:58:42 | Rock.Achu | set | messages: + msg150364 |
| 2011年12月30日 05:39:32 | Rock.Achu | set | messages: + msg150363 |
| 2011年12月30日 05:37:33 | Rock.Achu | set | messages: + msg150362 |
| 2011年12月30日 05:36:04 | Rock.Achu | set | messages: + msg150361 |
| 2011年12月30日 05:35:12 | Rock.Achu | set | messages: + msg150360 |
| 2011年12月30日 05:26:38 | Rock.Achu | set | messages: + msg150359 |
| 2011年12月30日 04:53:44 | Rock.Achu | set | messages: + msg150358 |
| 2011年12月30日 04:50:16 | Rock.Achu | set | messages: + msg150357 |
| 2011年12月30日 04:42:56 | Rock.Achu | set | files:
+ error.txt messages: + msg150356 |
| 2011年12月30日 04:39:42 | Rock.Achu | create | |