[PD-dev] [ pure-data-Bugs-3458347 ] spec2_sqrt~.c won't work in double precision, violates C99
Bugs item #3458347, was opened at 2011-12-12 11:43 Message generated for change (Tracker Item Submitted) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3458347group_id=55736 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: musil (tmusil) Summary: spec2_sqrt~.c won't work in double precision, violates C99 Initial Comment: spec2_sqrt~.c includes type punning, which violates the C99 standard, breaks when t_float/t_sample are 64-bit doubles, and also breaks modern compiler optimizations. Here's the compiler warning: pd-extended/externals/iem/iem_spec2/src/spec2_sqrt~.c:28: warning: dereferencing type-punned pointer will break strict-aliasing rules -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=478070aid=3458347group_id=55736 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
[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@iem.at http://lists.puredata.info/listinfo/pd-dev
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 cz...@chopin.edu.pl To: pd-dev pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Pre-existing bug report: http://sourceforge.net/tracker/index.php?func=detailaid=2621932group_id=55736atid=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 jancs...@yahoo.com To: Krzysztof Czaja cz...@chopin.edu.pl; pd-dev pd-dev@iem.at Cc: Ivica Ico Bukvic i...@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 cz...@chopin.edu.pl To: pd-dev pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
Hey Krzysztof, Glad to see you posting again on pd-dev! :) Thanks for the breakdown on the bug, that should be helpful, especially combined with pd-l2ork. Jonathan, do you know which release date introduced this fix in pd-l2ork? Then we can isolate it. Otherwise its difficult to navigate the pd-l2ork commit history. .hc On Mon, Dec 12, 2011, at 17:40, Jonathan Wilkes wrote: 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 cz...@chopin.edu.pl To: pd-dev pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] deadly leak
- Original Message - From: Hans-Christoph Steiner h...@at.or.at To: Jonathan Wilkes jancs...@yahoo.com; Krzysztof Czaja cz...@chopin.edu.pl; pd-dev pd-dev@iem.at Cc: Ivica Ico Bukvic i...@vt.edu Sent: Monday, December 12, 2011 9:40 PM Subject: Re: [PD-dev] deadly leak Hey Krzysztof, Glad to see you posting again on pd-dev! :) Thanks for the breakdown on the bug, that should be helpful, especially combined with pd-l2ork. Jonathan, do you know which release date introduced this fix in pd-l2ork? Then we can isolate it. Otherwise its difficult to navigate the pd-l2ork commit history. The comment in the changelog I referenced below was from 2011-03-26. In 2011-04-03 there's this: *removed some of the workarounds for the aforesaid double-entry bug which proved to be fixes for the symptoms rather than the core problem Then in 2011-04-11: *finally discovered the root of all double-entry bugs (fingers crossed) and reverted all other previous workarounds for this problem. That's the last entry in the changelog I see that is related to this issue, but I only tested my crasher patch on 2011-12-09 to confirm that the crash or double-entry is indeed gone in this case with Pd-l2ork. -Jonathan .hc On Mon, Dec 12, 2011, at 17:40, Jonathan Wilkes wrote: 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 cz...@chopin.edu.pl To: pd-dev pd-dev@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@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
