Community
Peter,
I can see from your communications from Shyam that an issue was identified and fixed earlier this year. But obviously that is not the only issue you are dealing with.
There are two ways that event handlers are removed from there events. The first as you mentioned is explicitly calling the 'remove' method on the Event object, passing in the exact same EventHandler reference passed to the 'add' method. The second is when the EventHandler instance goes completely unreferenced and it is garbage collected and destroyed. EventHandler destruction will remove itself from Events that it was attached to.
For the 'Event.remove' method, the contract for this API is that it will return 'True' once it successfully ensures that the specified handler is not attached to the event. This method is idempotent. So yes, calling it with a handler that has already been removed (or was never attached) is not a failure. For a garbage collected language like Python, the most deterministic way to ensure the event handlers are removed from events is to call the remove method.
For the event handler destruction method, this relies on you being able to ensure that all references in your application go unreferenced when your addin stops. If you are careful to only hold references to these handlers in one place (like a 'handlers' global only held by the main module of the addin), this normally wouldn't be a problem. But if you hold references to your handler instances in submodules, or start adding them to the global dictionary of the debug console, then it can easily get out of hand trying to keep track them. Especially because imported modules aren't released from sys.modules by default when referencing modules are unloaded, so any references held by them will not go away either. (A C++ client would typically not have issues like this as destruction order is normally deterministic.)
In production addins aren't (normally) expected to be stopped frequently, so this is mostly a development issue. But The addin samples normally rely on the 'release all references to handlers' method (by just clearing a global 'handlers' list). But if this is not normally a good solution for the way your code is structured or the way you work, I would recommend going with the deterministic 'remove' method. A simple example doing this could look something like the following:
import adsk.core, adsk.fusion, traceback
from typing import Callable, List, NamedTuple
import weakref
app: adsk.core.Application
ui: adsk.core.UserInterface
class Handler(NamedTuple):
handler: any
event: weakref.ReferenceType
handlers: List[Handler] = []
def run(context):
global app, ui
try:
app = adsk.core.Application.get()
ui = app.userInterface
event = app.documentActivated
event.add(createHandler(adsk.core.DocumentEventHandler, onDocumentActivated, event))
ui.messageBox('Simple Addin Running')
except:
if ui:
ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))
def stop(context):
global app, ui
try:
clearHandlers()
if ui:
ui.messageBox('Simple Addin Stopped')
except:
if ui:
ui.messageBox('Failed:\n{}'.format(traceback.format_exc()))
finally:
app = None
ui = None
def onDocumentActivated(args: adsk.core.DocumentEventArgs):
ui.messageBox("Document '{}' activated".format(args.document.name))
def defineHandler(handlerType, callback):
class Handler(handlerType):
def __init__(self):
super().__init__()
def notify(self, args):
try:
callback(args)
except:
message = 'notify failed: {}'.format(traceback.format_exc())
if ui:
ui.messageBox(message)
print(message)
return Handler
def createHandler(handlerType, callback: Callable, event: adsk.core.Event):
handler = defineHandler(handlerType, callback)()
handlers.append(Handler(handler, weakref.ref(event)))
return handler
def clearHandlers():
global handlers
for handler in handlers:
event = handler.event()
if event:
event.remove(handler.handler)
handlers = []
Of course in development, bad things happen. So if you ever stopped/crashed out of your script before releasing all your handlers, you would have lost your references to your handlers so you would have to track down what is referencing them and release those. Typically, this would be from an imported modules. You could look in the 'sys.modules' dictionary in the Fusion python console for your modules (e.g. 'sys.modules.keys()'), and force remove them and trigger a garbage collection (sometimes it takes a few passes for modules). E.g.:
import sys
del sys.modules[mySubModuleKey]
import gc
gc.collect()
gc.collect()
I can also create an issue to force remove all handlers created by a script when that script is stopped. I would think a script should still deterministically handle its callback registrations, but this could act as a (sledgehammer) backstop.
Kris
Kris Kaplan
FYI: With the release earlier this week, we now force release any event handlers created by an addin that are left connected after stopping the addin. Assuming you can reproduce your issue, give it a try again and let me know how things look.
FWIW: I also added a 'APIDebug.EventHandlers' text command to list connected handlers and the scripts that own them, and 'APIDebug.ReleaseEventHandlers' to release all of the event handlers for a specific addin at any time.
Kris
Kris Kaplan
It's a little hard to divine what might be going wrong in your handler. Does it run correctly, and just has problems when you are debugging through it? It sounds like perhaps your notify handler threw an exception (which if in the command created event on the definition will terminate the command). And the handler only getting triggered once sounds like either the script is getting stopped, or the event handler was removed. If you can provide a simplified sample with precise steps to reproduce, I can try to debug through it and see what is happening.
From the steps you mentioned, the command started, terminated, and your command created event sequence seems normal. The sequence would normally be:
1. UI start a command (click command button, etc...).
2. Command started event is fired (before starting the sequence of starting the command).
3. Unfortunately, if the command is started from a button click, the started event is fired twice (once by the command click, and one from the command manager). Ideally, one of these should be filtered out to avoid the duplication, but for now you can just ignore this.
4. The api command definition's command created event is fired to create the new command.
5. The current command is ended and the command terminated event is fired.
There is always a command running (normally, when it appears that no command is active the 'select command' is running). So after step 5 above, your command and input events should determine the command lifetime. From the events we talked about so far, if your command terminates or is cancelled for any reason, the sequence starts over at step 2 (starting either the select command or the interrupting command that was started).
So in your sequence below, everything looks normal until you get to your item 5. That 'start' indicates that your command is ending, and a new one is starting. Your command ending could either be that it never started (create command event failed), or all the command inputs are valid (or there were none) and you returned from your execute handler (or didn't have one connected). And not firing again should mean that either the event handler was removed (either explicitely, by dropping all references to it, or by your script module getting unloaded), or the debug session terminated (but you would have noticed that).
APIDebug is a text command. It is available on the 'Text Commands' pallet in the UI (File --> View --> Show Text Commands menu). With the 'Txt' checkbox in the text command window, if you run the 'apidebug' command, it should list the available commands. And if you run 'apidebug.eventhandlers' it will dump a line for every event handler currently attached to an event.
Kris
Kris Kaplan
Glad you found it.
Yes. Errors raised during event callbacks can be hard to identify. That's why I would consider wrapping every event handler notification function in a try catch block and make noise (messagebox, breakpoint(), whatever) in debug builds and ideally event logging in a production app when they catch.
Kris
Kris Kaplan
Peter,
What this debug command is doing is looping over all of the Event objects that are still referenced and alive, and loops over all of the attached event handlers to print out which script owns each handler. The assumption was that normally the only references to Event objects would be from the EventHandlers that are attached to them. But what your output is showing is that there is apparently code that is still holding references to these Event objects after the point that the event handlers have been detached from them (which normally happens when the event handler is destroyed or Event.remove was explicitly called for that handler). I can easily filter out live Event objects that have no event handlers attached to them in a future release.
The code that iterates these event handlers for this output is basically the same that is used to notify these handlers. So this means that any handlers that were attached to these will not be notified if those events are triggered.
I think what you are describing sounds more like the code you are debugging over is just not matching the code that is currently loaded and running (I know, that was the story all along). And the original assumption was that this was due to leaked EventHandler references was the culprit. But it seems fairly apparent from the event handler dump that this is not the actual cause. All of those Event object references are likely coming from your code (assuming that was the only API script activity during your debug session). And those Event references are likely from your module objects, meaning that your modules didn't unload.
Fusion addin/script main entrypoint modules are removed from the system modules dictionary when they are stopped to allow them to reload when re-run. We will also attempt to unload any modules that are loaded relative to the main module. But if you load your script's modules in some other way (like by adding your folder to the sys path and load them absolute), then they will remain referenced by the sys.modules dict and will not reload when you re-run your script. So the first recommendation would be to try to always use relative imports for all of your addin's sub-modules, and only use absolute (sys.path) imports for shared standard modules (which should not change, even during development). If for some reason, you need to use absolute imports for code you want to change during development, then you need to remove those modules from sys.modules explicitly. Perhaps the easiest way to do this would be with importlib.reload. For example:
import sub1, sub2
if debugging:
import importlib
importlib.reload(sub1)
importlib.reload(sub2)
But take note of some of the details about details in the 'reload' documentation. Otherwise, you could do a manual 'reload' with something like:
import sub1
if debugging:
# reload
import sys
global sub1
del sub1
del sys.modules[sub1.__loader__.name]
import sub1
But going with relative imports would be ideal so it 'just happens'.
Kris
Kris Kaplan
Peter,
I pulled that code and after various rounds of running, stopping, debugging, stepping, detaching, etc... I have not yet seen it leave any of its modules loaded after stopping the addin. I did not notice anything that stood out to me (other than extending sys.path which would normally be a red flag, but that doesn't seem to be used or necessary in this code or any of its imports). If you can easily reproduce this with some simple sequence of steps, let me know and I can try.
As for the logger file handle, I'm not sure what could be holding that open, especially after explicitly closing the FileHandler. Is it possible that there is another addin or script running with a logger using the same name (although releasing it on stop should still kill it)?
You could try looking at the dependency graph of the garbage collector using something like https://mg.pov.lt/objgraph/ once you get into this scenario. But you will likely want to stop every script except yours, and probably also minimize the code to just what's necessary to see this (or the graph could be overwhelming).
Kris
Kris Kaplan
Can't find what you're looking for? Ask the community or share your knowledge.
Post to forums
