erp... sorry... figured it out. I didn't assign a free method when I instantiated the object, so myObj_free() wasn't getting called... duh.

Come to think of it, is there any "best practice" when implementing class_free() in an external - something similar to [super release] in obj-c?? I've seen sample code that doesn't implement class_free() at all, so I'm assuming the runtime has a default method, for cases where it hasn't been implemented. But probably we have to handle this manually once we implement it, yes?

Thanks Nicolas. But this isn't quite the answer I was looking for. In obj-c, when you override -dealloc: you are responsible for making sure everything that would have happened still happens. That's why the common practice is to include a [super dealloc] (sorry, I said [super release] above, which was wrong), to be sure that an object's supercalss releases any objects that it created. I was just wondering whether implementing class_free() carried a similar responsibility - that is, do I have to call some particular method to ensure that the object's data is freed. As I mentioned earlier, I want to release the obj-c objects (well, pointers) I include in my Max object's struct, so I'm doing something like this (hacked into the plussz sample code):

void plussz_free(t_plussz *x) { [x->dict release]; // free plussz's NSMutableDictionary before the Max object is gone! }

This just makes sure the NSMutableDictionary "dict" gets released (which couldn't happen otherwise), but it doesn't do anything about the struct's other fields. I tried sysmem_freeptr() and object_free(), the latter of which crashed Max. Since the object is created in plussz_new() using object_alloc(), then object_free() should be the correct method, according to the docs... So, I'm guessing the crash is telling me not to mess around with freeing the struct...