I guess this is primarily for devs:
The title says it all. When pd starts up, it does 2 instances of canvas_new() calls. More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases.
NB: Not sure if this makes any difference but this is pd-l2ork code based on pd-extended...
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: pd list pd-list@iem.at; pd-dev@iem.at Cc: Sent: Sunday, December 11, 2011 3:39 AM Subject: [PD] pd at startup creates 2 canvases, why?
I guess this is primarily for devs:
The title says it all. When pd starts up, it does 2 instances of canvas_new() calls.
They contain templates for arrays.
[; pd-_float vis 1; pd-_float_array vis 1 (
More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases.
They aren't listed in the "Window" menu. But like any other canvas, you can send them objects and messages:
[; pd-_float obj 20 20 keyname, obj 20 80 print all_your_keys_are_belongs_to_us, connect 1 1 2 0 (
NB: Not sure if this makes any difference but this is pd-l2ork code based on pd-extended...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
They contain templates for arrays.
[; pd-_float vis 1; pd-_float_array vis 1 (
More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases.
They aren't listed in the "Window" menu. But like any other canvas, you can send them objects and messages:
[; pd-_float obj 20 20 keyname, obj 20 80 print all_your_keys_are_belongs_to_us, connect 1 1 2 0 (
OK, so that explains why they are created. However, this does not answer the question why they are not being destroyed when exiting pd. Neither canvas_free nor glist_free are triggered when quitting pd, so this must be a memory leak, no?
Ico
On 2011-12-11 12:14, Ivica Ico Bukvic wrote:
They contain templates for arrays.
[; pd-_float vis 1; pd-_float_array vis 1 (
More interestingly, it does not do canvas_free for those two instances when closing pd, suggesting this is a memory leak. So, what gives? Why does it create 2 invisible canvases, what is their function, and how do they differentiate from the regular canvases.
They aren't listed in the "Window" menu. But like any other canvas, you can send them objects and messages:
[; pd-_float obj 20 20 keyname, obj 20 80 print all_your_keys_are_belongs_to_us, connect 1 1 2 0 (
OK, so that explains why they are created. However, this does not answer the question why they are not being destroyed when exiting pd. Neither canvas_free nor glist_free are triggered when quitting pd, so this must be a memory leak, no?
The OS releases all the memory allocated by the process when it terminates, so no.
Martin
On 12/11/2011 06:14 PM, Ivica Ico Bukvic wrote:
OK, so that explains why they are created. However, this does not answer the question why they are not being destroyed when exiting pd. Neither canvas_free nor glist_free are triggered when quitting pd, so this must be a memory leak, no?
as martin has explained, it is not a memory leak. nevertheless, there are some problems with not calling the destructors, esp. when it comes to shared usage of resources. there is a patch in the patch tracker [1] that tries to fix this.
gmasdr IOhannes
[1] http://sourceforge.net/tracker/?func=detail&aid=1502860&group_id=557...
-
IOhannes zmölnig -
Ivica Ico Bukvic -
Jonathan Wilkes -
Martin Peach