osbrain: Nonetype error when calling shutdown in Osbrain

I usually get an exception anytime I call the shutdown method on the nameserver. A simplified case is shown below.

Windows 10 Python 3.7 (I tried it with 3.5, 3.6 versions as well) Osbrain 0.6.5

from osbrain import run_nameserver,run_agent,Agent

class Car(Agent):
    def on_init(self):
        self.set_attr(color='Red')
    def move(self, distance, time):
        self.speed = distance / time
        print(self.speed)

class Main:
    def __init__(self, num_cars):
        self.ns = run_nameserver()
        self.cars_dict = {}
        for i in range(1, num_cars + 1):
            self.cars_dict[f'Car-{i}'] = run_agent(f'Car-{i}', base=Car, serializer='json')

    def run(self):
        for car_name_a, car_a in self.cars_dict.items():
            car_a.move(3, 5)


if __name__ == '__main__':
    main = Main(5)
    main.run()
    main.ns.shutdown()

The above throws the following error:

Exception ignored in: <function Socket.del at 0x000002650054B318> Traceback (most recent call last): File “C:\Users\user\Anaconda3\envs\envs-3\lib\site-packages\zmq\sugar\socket.py”, line 67, in del File “C:\Users\user\Anaconda3\envs\envs-3\lib\site-packages\zmq\sugar\socket.py”, line 105, in close File “C:\Users\user\Anaconda3\envs\envs-3\lib\site-packages\zmq\sugar\context.py”, line 153, in_rm_socket TypeError: ‘NoneType’ object is not callable

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 16 (9 by maintainers)

Most upvoted comments

@Peque I will consider using Linux in the near future, but not now because my current project requires a Windows machine.

Unfortunately, I am still getting the Nonetype error, but as @ocaballeror mentioned, it seems that the error is from python logging which you guys have no control on?. If that is the case, then you can close it. Thanks!

Blankslide on May 31, 2020

@Peque yeah, I mean it never ends. The issue is the same in the example I posted: one of the messages never arrives to the subscriber, and so the publisher waits forever for a response. I’m opening a new issue to discuss.

ocaballeror on May 30, 2020

Still can’t reproduce the issue for the first example. Did you change any of the configuration options for Pyro4? I see in the traceback that the issue seems to arise somewhere in the logging library. Perhaps you set the PYRO_LOGLEVEL to DEBUG? When doing that I run into a similar issue when the nameserver shuts down:

Exception ignored in: <bound method Proxy.__del__ of <osbrain.proxy.NSProxy at 0x7f0f06bf4a20; not connected; for PYRONAME:Pyro.NameServer@127.0.0.1:18189>>
Traceback (most recent call last):
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/site-packages/Pyro4/core.py", line 266, in __del__
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/site-packages/Pyro4/core.py", line 400, in _pyroRelease
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1296, in debug
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1444, in _log
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1454, in handle
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1516, in callHandlers
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 865, in handle
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1071, in emit
  File "/home/oscar/.miniconda/envs/osbrain36/lib/python3.6/logging/__init__.py", line 1061, in _open
NameError: name 'open' is not defined

Which seems to be a problem with Python’s logging module itself: https://bugs.python.org/issue26789

I don’t see much we can do about that from our side, but the somewhat “good” part about it is that the exception is automatically ignored (notice how the error starts with “Exception ignored in…”), and it doesn’t break anything from your code, so you could more or less ignore it for the time being.

@Peque can you take a look at the second example? It hangs 90% of the time, even on Linux, because the second agent doesn’t receive the message, but I can’t seem to figure out why. Consider this code, which is a simplification of the example @Folorunblues posted:

import time
from osbrain import run_nameserver, run_agent, Agent

def log_msg(agent, msg):
    agent.log_info('Received: %s' % msg)

class ListAgent(Agent):
    def on_init(self):
        self.received = []
    
    def append(self, msg):
        self.log_info('Received %s' % msg)
        self.received.append(msg)

    def idle(self):
        self.log_info('Nothing to process')

class MasterAgent(Agent):
    def on_init(self):
        self.both_received = False
        self.addr = self.bind("SYNC_PUB", alias='main', handler=log_msg)

    def start(self):
        agent1 = run_agent('Agent1', base=ListAgent)
        agent2 = run_agent('Agent2', base=ListAgent)
        agent1.connect(self.addr, handler="append")
        agent2.connect(self.addr, handler="append")
        self.send('main', 'Hello world')
        time.sleep(2)
        recv1 = bool(agent1.get_attr('received'))
        recv2 = bool(agent2.get_attr('received'))
        self.both_received = recv1 and recv2

if __name__ == "__main__":
    ns = run_nameserver()
    master = run_agent('Master', base=MasterAgent)
    master.start()
    try:
        assert master.get_attr('both_received')
    finally:
        ns.shutdown()

Shouldn’t this work? It seems to be a problem with the SYNC_PUB pattern, since you can get it to work by changing the socket type to just PUB. I’m confused 😕 .

ocaballeror on May 30, 2020

True. It looks so similar I thought you posted the same message again by accident 😅

Still, I was not able to reproduce the error on Windows 10 with the versions that you specified. Your code ran perfectly fine on my machine.

@Folorunblues care to post the full output of pip freeze? Maybe we can pin down the error that way.

ocaballeror on May 29, 2020

Good to know this is fixed! 😊

Closing this issue then. Good luck with your projects!

Peque on May 17, 2020

@Peque Finally I was able to figure out the cause of the exception error, I knew it was from the pyzmq that osbrain is using. Fortunately for me, an issue was opened here regarding the exception:https://github.com/zeromq/pyzmq/issues/1356. The fix is to upgrade to the latest version of pyzmq (19.0.1). After I upgraded pyzmq, the nameserver was able to shut down without any error.

Regarding Linux, I have a computer that runs ubuntu at work, but I don’t use it that much because I am a lazy programmer:)

Blankslide on May 17, 2020