Import concurrent.futures in a python script cause error "atexit" on blenderplayer #39399

New Issue

Giulio · 2014-03-24T22:55:33+01:00

Giulio commented

2014-03-24 22:55:33 +01:00

System Information
First computer:
Operating system: Linux 3.11.0-18-generic #32~precise1-Ubuntu SMP Thu Feb 20 17:52:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Graphics card: nvidia Geforce GTS 250

Second computer:
Operating system: 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux
Graphics card: nvidia G98M

Blender Version
First computer: Version 270 sub 0 date 2014-03-20 17:45 hash dfa5ced
Second computer: ver 2.69.0

Short description of error
The import of python library "concurrent.futures", due to the registration method atexit, causes the error:

First computer:

Error in atexit._run_exitfuncs:
AttributeError: 'NoneType' object has no attribute 'items'

Second computer:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.3/concurrent/futures/thread.py", line 34, in _python_exit
items = list(_threads_queues.items())
AttributeError: 'NoneType' object has no attribute 'items'
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.3/concurrent/futures/process.py", line 78, in _python_exit
items = list(_threads_queues.items())
AttributeError: 'NoneType' object has no attribute 'items

You can see the error if you run the project using blenderplayer from a shell.

Exact steps for others to reproduce the error

Run the project with blenderplayer from shell
Press the ESC key

If you need other information, just ask.

**System Information** First computer: Operating system: Linux 3.11.0-18-generic #32~precise1-Ubuntu SMP Thu Feb 20 17:52:10 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Graphics card: nvidia Geforce GTS 250 Second computer: Operating system: 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64 GNU/Linux Graphics card: nvidia G98M **Blender Version** First computer: Version 270 sub 0 date 2014-03-20 17:45 hash dfa5ced Second computer: ver 2.69.0 **Short description of error** The import of python library "concurrent.futures", due to the registration method atexit, causes the error: First computer: Error in atexit._run_exitfuncs: AttributeError: 'NoneType' object has no attribute 'items' Second computer: Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib/python3.3/concurrent/futures/thread.py", line 34, in _python_exit items = list(_threads_queues.items()) AttributeError: 'NoneType' object has no attribute 'items' Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/lib/python3.3/concurrent/futures/process.py", line 78, in _python_exit items = list(_threads_queues.items()) AttributeError: 'NoneType' object has no attribute 'items You can see the error if you run the project using blenderplayer from a shell. **Exact steps for others to reproduce the error** 1. Run the project with blenderplayer from shell 2. Press the ESC key If you need other information, just ask.

Giulio commented

2014-03-24 22:55:33 +01:00

Changed status to: 'Open'

Giulio commented

2014-03-24 22:55:33 +01:00

Added subscriber: @Trixymoon

Mitchell Stokes commented

2014-03-25 01:37:12 +01:00

Added subscriber: @Moguri

Mitchell Stokes commented

2014-03-25 01:37:12 +01:00

I'm not really sure what to do with this report. Is there something that the BGE is or isn't doing that causes this problem? In other words is it a Python issue or a BGE issue?

Giulio commented

2014-03-25 04:32:41 +01:00

First of all I apologize for my poor English.

The problem arises only when you use the library python "concurrent.futures" within blenderplayer, in fact the import and use of the library inside blender not pose any problems, there is no problem in using this library outside of blender as pure python scripts.
In fact, the library itself works without any problem.
The methods registered by atexit inside the library "concurrent.futures" create problems with atexit registered by blenderplayer.

I apologize if I used the tag incorrectly.
I remain at your disposal.

First of all I apologize for my poor English. The problem arises only when you use the library python "concurrent.futures" within blenderplayer, in fact the import and use of the library inside blender not pose any problems, there is no problem in using this library outside of blender as pure python scripts. In fact, the library itself works without any problem. The methods registered by atexit inside the library "concurrent.futures" create problems with atexit registered by blenderplayer. I apologize if I used the tag incorrectly. I remain at your disposal.

Giulio commented

2014-03-25 05:01:14 +01:00

um, I re-read what I wrote and I have found it incomprehensible this time too. Sorry.
Short answer I think it is a problem of bge.
The atexit used whitin bge should not create problems with the python standard libraries.
Sorry again. I need some sleep.
I remain at your disposal, Giulio.

um, I re-read what I wrote and I have found it incomprehensible this time too. Sorry. Short answer I think it is a problem of bge. The atexit used whitin bge should not create problems with the python standard libraries. Sorry again. I need some sleep. I remain at your disposal, Giulio.

Mitchell Stokes commented

2014-04-24 09:24:12 +02:00

Added subscriber: @ideasman42

Mitchell Stokes commented

2014-04-24 09:24:12 +02:00

As far as I can tell, the Blenderplayer doesn't mess with Python's atexit...

I'm guessing there is something the the Blenderplayer needs to do (some Python C API call, but I don't know what it is). Campbell, do you know anything about this?

As far as I can tell, the Blenderplayer doesn't mess with Python's atexit... I'm guessing there is something the the Blenderplayer needs to do (some Python C API call, but I don't know what it is). Campbell, do you know anything about this?

Angus Hollands commented

2014-04-28 22:57:28 +02:00

Added subscriber: @AngusHollands-4

Angus Hollands commented

2014-04-28 22:57:28 +02:00

This is caused (I believe) by the main thread exiting before the other threads close, so all references become None.
I have the same issue in my multi-player system which spawns threads.

To try fixing this, close the BGE yourself using an ESC key sensor, and do the following:

http://www.pasteall.org/51192/python

This is caused (I believe) by the main thread exiting before the other threads close, so all references become None. I have the same *issue* in my multi-player system which spawns threads. To try fixing this, close the BGE yourself using an ESC key sensor, and do the following: http://www.pasteall.org/51192/python

Mitchell Stokes commented

2014-04-29 00:55:39 +02:00

I'm not seeing an error with the supplied test file (I'm using the Blenderplayer).

Angus Hollands commented

2014-04-30 21:46:12 +02:00

That's because (IIRC) of how the BGE finishes with the Python environment when the internal player exits. It shouldn't exist in the external player (I don't think)

Giulio commented

2014-05-01 18:30:17 +02:00

@Moguri
"I'm not seeing an error with the supplied test file (I'm using the Blenderplayer)."

Well, this is getting triky! What version of blenderplayer are you using? Which OS?
I'm using blender released by irie ppa, on Mint 13 LTS.
Well I’m waiting for next Mint release based on 14.04 to upgrade my OS.
I had the same error on debian testing, which is the OS that is using a friend of mine.
I still have not been able to test the code on a Windows machine...

@AngusHollands-4
"To try fixing this, close the BGE yourself using an ESC key sensor, and do the following"

Ok, this is working well. With your workaround i can use concurrent.futures on my code. Good!
I was already using a ESC key sensor for free the resources and killing the threads on my project.
I also implemented the signals handling to release the resources, given that the project that I am developing is meant to be launched via ssh into a remote machine, and yes, i am aware that the functions registered with atexit are not performed if the program is killed by a signal is not handled by the python code.
(see https://docs.python.org/3.3/library/atexit.html)
However, explicitly call the atexit function it is not the purpose for which the function has been designed for.
"..function registered are automatically executed upon normal interpreter termination" (python doc)
Well in my environment, only the import library "concurrent.futures" generates the error on atexit.

"That's because (IIRC) of how the BGE finishes with the Python environment when the internal player exits. It shouldn't exist in the external player (I don't think)"

I understand what you're saying.. i get the same problem when i switch scene in blender project (sig).
In any case, in my code I have to get tons of OSC messages from UDP socket, which is set in blocking mode: I need threads.
Thanks agoose77, you've been a great help.
I put the code that I mentioned before, purged by the OSC parser.
Sorry for the tabs in the code, it is an old habit... (see test2.zip)

Ps.
I got segmentation fault when i lunched the game engine inside blender using the project " test2.zip ", while in blenderplayer is working perfectly.
If I comment out the line "atexit._run_exitfuncs()", i have no error on blender (and of course i get the error on atexit back in blenderplayer).
Well, I do not know what's going on anymore..
I really want to bump my head against a wall...

I remain at your disposal. Giulio

(edit reason: my english sucks...)

@Moguri "I'm not seeing an error with the supplied test file (I'm using the Blenderplayer)." Well, this is getting triky! What version of blenderplayer are you using? Which OS? I'm using blender released by irie ppa, on Mint 13 LTS. Well I’m waiting for next Mint release based on 14.04 to upgrade my OS. I had the same error on debian testing, which is the OS that is using a friend of mine. I still have not been able to test the code on a Windows machine... @AngusHollands-4 "To try fixing this, close the BGE yourself using an ESC key sensor, and do the following" Ok, this is working well. With your workaround i can use concurrent.futures on my code. Good! I was already using a ESC key sensor for free the resources and killing the threads on my project. I also implemented the signals handling to release the resources, given that the project that I am developing is meant to be launched via ssh into a remote machine, and yes, i am aware that the functions registered with atexit are not performed if the program is killed by a signal is not handled by the python code. (see https://docs.python.org/3.3/library/atexit.html) However, explicitly call the atexit function it is not the purpose for which the function has been designed for. "..function registered are automatically executed upon normal interpreter termination" (python doc) Well in my environment, only the import library "concurrent.futures" generates the error on atexit. "That's because (IIRC) of how the BGE finishes with the Python environment when the internal player exits. It shouldn't exist in the external player (I don't think)" I understand what you're saying.. i get the same problem when i switch scene in blender project (sig). In any case, in my code I have to get tons of OSC messages from UDP socket, which is set in blocking mode: I need threads. Thanks agoose77, you've been a great help. I put the code that I mentioned before, purged by the OSC parser. Sorry for the tabs in the code, it is an old habit... (see test2.zip) Ps. I got segmentation fault when i lunched the game engine inside blender using the project " [test2.zip](https://archive.blender.org/developer/F86566/test2.zip) ", while in blenderplayer is working perfectly. If I comment out the line "atexit._run_exitfuncs()", i have no error on blender (and of course i get the error on atexit back in blenderplayer). Well, I do not know what's going on anymore.. I really want to bump my head against a wall... I remain at your disposal. Giulio (edit reason: my english sucks...)

Mitchell Stokes commented

2014-05-02 00:00:30 +02:00

I am using Arch Linux 64bit, and a version of the Blenderplayer built from master. Maybe the switch to Python 3.4 fixed something?

Giulio commented

2014-05-21 19:06:17 +02:00

I received an update via irie blender ppa...
Blnder now uses python 3.4 and I no longer have the error that I pointed out!

Great!
Whatever the problem was, it was solved by changing the version of python.

Thank you all for the help.

Giulio

I received an update via irie blender ppa... Blnder now uses python 3.4 and I no longer have the error that I pointed out! Great! Whatever the problem was, it was solved by changing the version of python. Thank you all for the help. Giulio

Mitchell Stokes commented

2014-05-21 21:57:24 +02:00

Changed status from 'Open' to: 'Resolved'

Mitchell Stokes closed this issue

2014-05-21 21:57:24 +02:00

Mitchell Stokes self-assigned this 2014-05-21 21:57:24 +02:00

Sign in to join this conversation.