Hi,
I may be completely wrong about this, but it seems like PD runs the 'free' function for each object class on a canvas if a window is explicitly closed, but not if 'quit' is selected from the file menu (when there are canvases still open).
For example, if I write a very simple object:
static t_class *mem_class;
typedef struct _mem { t_object x_obj; char *memory; } t_mem;
static void *mem_new(t_symbol *s, t_int argc, t_atom *argv) { t_mem *x = (t_mem *)pd_new(mem_class); x->memory = malloc(10000); return (void *)x; }
static void mem_free(t_mem *x){ free(x->memory); }
void mem_setup(void) { mem_class = class_new(gensym("mem"), (t_newmethod)mem_new, (t_method)mem_free, sizeof(t_mem), CLASS_DEFAULT, 0); }
If I close the the canvas before quiting the memory gets free'd properly, whereas if I just select 'quit' whilst the canvas is still open, the memory is still reachable.
Is this by design, and if so why? Or am I doing something wrong? Alternatively, should I report it as a bug?
Pd version 0.40-0test01
Regards,
Jamie
Hi Jamie,
Jamie Bullock schrieb:
I may be completely wrong about this, but it seems like PD runs the 'free' function for each object class on a canvas if a window is explicitly closed, but not if 'quit' is selected from the file menu (when there are canvases still open).
true, PD just bails out without freeing any resources -- the scheduler just exits. That also has been a problem for me lately, when using named semaphores under OSX, which must be freed otherwise they stay allocated in the OS. Miller, it would be great if we could find a way for PD to cleanly exit. This would also improve finding memory leaks with valgrind.
best greetings, Thomas