AttributeError raised during QueuePool garbage collection

Issue #297 resolved
Former user created an issue

I get following exception message:

Exception exceptions.AttributeError: "'NoneType' object has no attribute 'Empty'" in <bound method QueuePool.__del__ of <sqlalchemy.pool.QueuePool object at 0x025C10D0>> ignored

As far as i see, it happens during garbage collection at the end of process, but only in some specific circumstances (Queue module must be collected before pool module, which leads to Queue being None in QueuePool.dispose).

Replacing 'except Queue.Empty: ' with bareword except in QueuePool.dispose fixes the problem, but might have other consequences and is not an ideal fix in any case - due to quirks in Python GC whole issue would be better solved with weakrefs than del. Unfortunately, rewriting that is beyond me.

Comments (4)

  1. Former user Account Deleted

    Sorry for typos. Is there a way to register a non-guest account with this Trac instance so i can edit my own tickets?

  2. Mike Bayer repo owner
    • marked as minor
    • removed version

    the "Empty" exception is just Queue.Queue's way of saying "im empty", whereas anything else should halt execution since its an error....since its the "dispose" method which can be called at any time by user code, it should report errors.

    since this is occurring only when the process and everything is being removed, nothing is really breaking, its just the teardown of modules is not totally deterministic so strange conditions can arise. my impression is that this just goes with the territory when overriding the __del__() method, and this is more or less a cosmetic issue.

    or, we just take out __del__() from Pool altogether. im not sure exactly how it the "dispose" call got in there to start with, actually.

    we have another person on the IRC channel reporting this variant of the message:

    Exception exceptions.TypeError: <exceptions.TypeError instance at 0x00B634B8> in <bound method QueuePool.__del__ of <sqlalchemy.pool.QueuePool object at 0x011D0AD0>> ignored
    

    which is also an "upon shutdown" method. im not sure if theres some way to affect python so that it doesnt yank out the underlying framework from the code before running the code.

    id sort of rather take the __del__() call out altogether, or just wrap the exceptions called in __del__() itself.

  3. Log in to comment