On Wed, Jul 23, 2014 at 6:30 PM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote:
> On Wed, 23 Jul 2014 13:02:51 -0700, Jason Swails wrote: > > > I'm not sure how the "mylogger" variable is getting set to None in your > > my_error_handler callback, but I don't see how that can possibly be > > happening with the provided code... > > Dammit, it's a Heisenbug... now it's gone away for me too. > > http://c2.com/cgi/wiki?HeisenBug > > > However, I think I have a glimmer of an idea for how the global variable > might be set to None. When the Python interpreter shuts down, it sets > global variables to None in some arbitrary order. If the excepthook > function isn't called until after the shutdown process begins, then > depending on the phase of the moon, it's possible that ``mylogger`` may > have been set to None by the time it is called. > Looking at your code, it would seem like the shutdown process would happen when you call the original excepthook function (although Python quits whether or not that excepthook is called). How frequently do you observe this Heisenbug? The ones I've encountered were fairly reproducible, although those were more often caused by uninitialized variables or overwriting arrays -- not race conditions like this would seem to be (although unless it's threaded, how do we get a race condition?). Looking at the logging source code, threading is used, although it appears at a cursory glance to be more of a case of handling threaded applications rather than actually using threads to do any kind of work. A possible idea is to throw in a time.sleep(1) call after the call to mylogger.exception to see if that delays interpreter shutdown long enough for mylogger.exception to resolve. Of course if you can't reproduce the bug often enough, it'll be hard to tell if you've fixed it. The most unreliable Heisenbug I've ever fixed still happened ~1/3 of the time, so it was pretty obvious when I fixed it... All the best, Jason
-- https://mail.python.org/mailman/listinfo/python-list
