With the logging change to using weakrefs for handler cleanup done by the follow-on patch in issue 6615 exceptions may now be thrown during module teardown.

There are two distinct problem cases:
1) The new `_removeHandlerRef` function may run during teardown (when module globals are being set to None) but uses the module globals `_acquireLock`, `_releaseLock`, and `_handlerList`.
2) The `Handler.close` method no longer removes the instance from the module global list, this means if the caller then closes the underlying file but keeps a reference to the handler, the `shutdown` function will attempt to flush the already-closed file.

It may be that this new way of doing things is preferred and the response to closing underlying files or holding on to handler references is Don't Do That Then, but this seems like an accidental regression.

This could be fixed in a similar way to was done for the shutdown function in r51206 (which incidentally seems both unnecessary and incomplete - the function runs atexit which precedes module teardown, but also uses the raiseExceptions module global which is not rebound locally).

For the second case, just reverting the change to Handler.close may be best, I don't see why the module should be keeping responsibility for flushing and closing handlers it no longer has a strong reference to.

Fix checked into py3k and release27-maint (r84282).

Still randomly getting ignored exceptions on 3.3 and the default
branch, got for example:
Exception TypeError: TypeError("argument of type 'NoneType' is not
iterable",) in <function _removeHandlerRef at 0x7fcbe6014200> ignored

This happens in a threaded application. The root cause is explained in
http://bugs.python.org/issue1722344#msg62078
Instead of building a test case to reproduce the problem, the attached
teardown_module.py script is a contrived example that shows the issue
9501 is not fully fixed. Ignored exceptions appear randomly, so
teardown_module.py must be run in a loop, for example:

    $ while [ 1 ]; do python teardown_module.py; sleep .1; done

The attached patch fix the issue by testing all the globals used in
_removeHandlerRef and teardown_module.py runs fine with this patch
applied.

New changeset 966887830011 by Vinay Sajip in branch '2.7':
Issue #9501: Improved shutdown handling to deal with module attributes correctly.
http://hg.python.org/cpython/rev/966887830011

New changeset 8eac88f49cc0 by Vinay Sajip in branch '3.2':
Issue #9501: Improved shutdown handling to deal with module attributes correctly.
http://hg.python.org/cpython/rev/8eac88f49cc0

New changeset 3161a94ff73c by Vinay Sajip in branch '3.3':
Issue #9501: Merged fix from 3.2.
http://hg.python.org/cpython/rev/3161a94ff73c

New changeset 4fd8c35a05b2 by Vinay Sajip in branch 'default':
Issue #9501: Merged fix from 3.3.
http://hg.python.org/cpython/rev/4fd8c35a05b2

The reason why this happens in python 3.3.0 and not in 3.2:

1) lastResort holds a reference to an instance of _StderrHandler at
   module tear down, thus potentially triggering a TypeError in
   _removeHandlerRef.

2) The logging code has the following two lines that are meant to
   avoid the occurence of this problem:

    _defaultLastResort = _StderrHandler(WARNING)
    lastResort = _defaultLastResort

Issue 12637 describes another unrelated problem with lastResort in
python 3.2. As a workaround to this issue 12637, my application sets
lastResort to None and this works fine in 3.2 (the logging howto
states 'To obtain the pre-3.2 behaviour, logging.lastResort can be set
to None').  With python 3.3 it is this setting of lastResort to None
that causes these spurious 'exception ignored' messages, after
removing this setting no messages are printed anymore.

The initial teardown_module.py can be simply replaced with
(not a contrived example anymore) the following statements
to print the spurious ignored Exceptions:

# Run the script in a loop:
# while [ 1 ]; do python3 teardown_module.py; sleep .1; done
import logging
logging.lastResort = None
print('Fin')

Thanks for hunting these down. With the latest version, neither variant of the teardown script produces any error message on my system, either with 3.3 or 3.4 (default).

Yes, my last two messages refer to python 3.3.0 only.
The changes logged in http://bugs.python.org/issue9501#msg180039
do fix the behavior of both versions of teardown_module.py.