[PD-dev] deadly leak

Jonathan Wilkes jancsika at yahoo.com
Tue Dec 13 02:51:45 CET 2011


Pre-existing bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2621932&group_id=55736&atid=478070

I can confirm it still causes multiplicity in Pd-0.43.

I'll try the newest Pd-l2ork version in a bit to see whether it affects that one.

-Jonathan



----- Original Message -----
> From: Jonathan Wilkes <jancsika at yahoo.com>
> To: Krzysztof Czaja <czaja at chopin.edu.pl>; pd-dev <pd-dev at iem.at>
> Cc: Ivica Ico Bukvic <ico at vt.edu>
> Sent: Monday, December 12, 2011 8:40 PM
> Subject: Re: [PD-dev] deadly leak
> 
> HiKrzysztof,
>      I believe Ivica fixed this bug in Pd-l2ork back in March.  From 
> http://l2ork.music.vt.edu/data/pd/Changelog:
> *fixed problem where doubly-nested gops still caused double-entry bug after 
> cut/undo inside the abstraction.
> 
> 
> I haven't run into the double-entry problem in Pd-l2ork since then, but I 
> can confirm it's still a problem in 0.43.
> 
> -Jonathan
> 
> 
> ----- Original Message -----
>>  From: Krzysztof Czaja <czaja at chopin.edu.pl>
>>  To: pd-dev <pd-dev at iem.at>
>>  Cc: 
>>  Sent: Monday, December 12, 2011 8:15 PM
>>  Subject: [PD-dev] deadly leak
>> 
>>  Hi Pd gurus,
>> 
>>  ever found a single keystroke or a mouse click was duplicated
>>  on a patch?  A strange bug which always turns out to be fatal
>>  at the point of closing the patch?
>> 
>>  Hit by several such crashes one after another I went hunting.
>> 
>>  What I found was that there is always a t_editor created for
>>  a GOP graph.  The constructor is invoked by the first
>>  glist_findrtext() call aimed at anything inside of that GOP
>>  (this occurs when the parent is being mapped).
>> 
>>  Thus, the editor_new() for a GOP is called, but the
>>  corresponding editor_free() seems never to be called.
>> 
>>  The reason why this is not an innocent leak, but a crasher
>>  is quite subtle.
>> 
>>  For any t_editor, there is a t_guiconnect object created and
>>  bound to a symbol made up from the address of the editor's
>>  owner (a glist).  Since the editor is zombiefied, so is the
>>  guiconnect, and the symbol is never unbound.
>> 
>>  The trouble begins when another canvas is allocated at the
>>  address freed by the late owner of the zombie.  The editor is
>>  created, and a new t_guiconnect is bound to the old symbol.
>> 
>>  Now, if any message is sent to the symbol, it is caught by
>>  two t_guiconnect objects, both pointing to the same address:
>>  their 'x_who' pointer.  Hence, all messages from pd-gui to
>>  the new canvas are duplicated.  The agony is terminated by
>>  the second copy of the message 'menuclose'.
>> 
>>  I believe this bug has never been dealt with.  So, in case
>>  you consider it worthwhile, could someone forgive me my
>>  slothfulness and file this thing into the sf.net bug tracker
>>  or open a github's issue, whichever is more appropriate
>>  these days.
>> 
>>  Krzysztof
>> 
>>  _______________________________________________
>>  Pd-dev mailing list
>>  Pd-dev at iem.at
>>  http://lists.puredata.info/listinfo/pd-dev
>> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
> 



More information about the Pd-dev mailing list