Pd-dev February 2007

pd-dev@lists.iem.at

26 participants
44 discussions

Start a nNew thread

[ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
by SourceForge.net 13 Feb '07

13 Feb '07

5 19

[ pure-data-Bugs-1658570 ] [folder_list] glob patterns don't work on Windows
by SourceForge.net 13 Feb '07

13 Feb '07

Bugs item #1658570, was opened at 2007-02-12 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1658570&group_… 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: externals Group: v0.39.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Nobody/Anonymous (nobody) Summary: [folder_list] glob patterns don't work on Windows Initial Comment: [folder_list] should use glob patterns on Windows also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1658570&group_…

1 0

[ pure-data-Feature Requests-1657488 ] UI - Add a "Dont ask me again" to window close dialog.
by SourceForge.net 11 Feb '07

11 Feb '07

Feature Requests item #1657488, was opened at 2007-02-11 20:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1657488&group_… 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: puredata Group: None Status: Open Priority: 5 Private: No Submitted By: Danny Staple (orionrobots) Assigned to: Nobody/Anonymous (nobody) Summary: UI - Add a "Dont ask me again" to window close dialog. Initial Comment: When any window is closed in PD, a "Close this window??" dialog pops up every time. The suggestion is to add a toggle "Don't ask me again." to this dialog, and a preference to revive it to the PD menu should a user want to. This should be stored in the persistent preferences file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478073&aid=1657488&group_…

1 0

[ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
by SourceForge.net 11 Feb '07

11 Feb '07

Bugs item #1518030, was opened at 2006-07-06 11:54 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_… 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: puredata Group: v0.40.1 Status: Open Resolution: None Priority: 7 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Miller Puckette (millerpuckette) Summary: subpatch clearing itself crashes Pd Initial Comment: Tested on Linux with pd-0.39-2 from Miller's site. Steps to reproduce: start pd load the patch attached to this post click the bng close the patch load the patch again click the bng => crash OR start pd load the patch open the subpatch (optionally: close the subpatch) click the bng => crash Here's a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 27794)] pd_bang (x=0x11) at m_pd.c:269 269 m_pd.c: No such file or directory. in m_pd.c (gdb) where #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x0808a61b in outlet_bang (x=0x3) at m_obj.c:328 #2 0x080765ad in bng_bout2 (x=0x81f2790) at g_bang.c:294 #3 0x080767f6 in bng_newclick (z=0x11, glist=0x81f2338, xpix=74, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:343 #4 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #5 0x0805b557 in graph_click (z=0x81f2338, glist=0x11, xpix=74, ypix=70, shift=0, alt=0, dbl=17, doit=1) at g_graph.c:1059 #6 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #7 0x08070a97 in canvas_doclick (x=0x81ecd08, xpos=74, ypos=70, which=1, mod=0, doit=1) at g_editor.c:1094 #8 0x0807119d in canvas_mousedown (x=0x11, xpos=0, ypos=0, which=0, mod=0) at g_editor.c:1252 #9 0x08089789 in pd_typedmess (x=0x81ecd08, s=0x0, argc=0, argv=0x80cf488) at m_class.c:728 #10 0x08089665 in pd_typedmess (x=0x81f25f8, s=0x0, argc=4, argv=0x80cf468) at m_class.c:749 #11 0x0808c32f in binbuf_eval (x=0x11, target=0x81f25f8, argc=0, argv=0x0) at m_binbuf.c:574 #12 0x08091fdf in socketreceiver_read (x=0x81ec2f0, fd=7) at s_inter.c:540 #13 0x0809180f in sys_domicrosleep (microsec=17, pollem=1) at s_inter.c:180 #14 0x08092660 in sys_pollgui () at s_inter.c:823 #15 0x0808fe5b in m_scheduler () at m_sched.c:466 #16 0x08095b1b in main (argc=17, argv=0x11) at s_entry.c:27 ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-11 15:24 Message: Logged In: YES user_id=1709568 Originator: NO >But now we have a problem, if a message tries to commit suicide and >thus deletes the node that according to Pd's language rules and logic >needs to be evaluated again, after the "depth first tree" has come to >an end! When the moments come to evaluate the "second branch" of a node which has been deleted as a result of the execution of its first branch, the object no more exists, so the most logical action to take (seems to me) would be just not to execute the pending "future branches". The tree does finish. Another acceptable option would be to output an error message that says that the message tree can't be completed. Indeed that would be the same thing, with or without an error message in the output. The part you quote from the manual says that the message tree has to come to an end. It does not say that nothing must change until it comes to an end, as far as i see. You are adding that part. You may be correct, but that's not a consequence of the depth first message passing. Neither the self-clearing patch nor my "find f,cut" example try to generate a tree that does not end. Not to mention that in theese examples the branch that ends up with the deletion of the message is the last branch, so the evaluation of the next branch would be just to detect that it didn't exist anyway. >To be able to do this Pd has to save the current branching node >somehow to come back there later, when the first branch has finished. Yeah. It is the "somehow" that has been chosen that does not take into account the possibility of dinamically deleting objects. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-02-11 13:22 Message: Logged In: YES user_id=569446 Originator: NO Hi, sistisette wrote: > There's nothing semantically incorrect in doing that. There is. You may be missing some implications of Pd's "depth first message passing" as described in the manual, chapter "2.3.2. depth first message passing": [1] "Each message sets off a tree of consequent messages." As a message is generated by an object this also means that each (message) object sets off a tree of messages. Every branch of messages has to finish at some point. If it doesn't, you have an error in your patch, that will result in an infinite message loop or "stack overflow". The manual has an example for this, but you can also just bang an [until] without stopping it to make such a stack overflow without any backwards connections. Now how does this relate to "suicide" messages, that is, messages that will result in a deletion of the object that generated the message? Lets look at the [pd x] subpatch which has a [; pd-x clear( suidice message: As soon as you click this message, it will start a "message tree of consequent messages." This message tree has to finish, and the end point here would be the clearing of the subpatch including the message box that initiated the suidice. At first look this may seem okay, but a powerful and important feature of Pd is, that an object or message can be a node for several message branches. [trigger bang float] is one example for this: Pd will first execute the tree below the right float outlet completely, and when this is finished, it will come back to the [t b f] to work on the left bang outlet's tree. With messages this also is possible, e.g. by seperating messages with a comma or semicolon: [; pd-x clear; pd-x msg 100 100 hello world(: First this message will clear [pd x] then it will evaluate the second part of the message and put a "hello world" message into [pd x]. To be able to do this Pd has to save the current branching node somehow to come back there later, when the first branch has finished. But now we have a problem, if a message tries to commit suicide and thus deletes the node that according to Pd's language rules and logic needs to be evaluated again, after the "depth first tree" has come to an end! As the node was deleted, this is impossible, the correct data flow cannot be restored and that's why these messages indeed are semantically incorrect just like infinite message loops. Of course Pd should not die if someone attempts suidide, but still these kinds of messages are illegal constructs. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-10 19:45 Message: Logged In: YES user_id=1709568 Originator: NO Just another example that triggers the same bug (dunnow why I can't attach a file so I "transcribe" it here): [bng] | [f 0] | [find f, cut( | [s pd-thisFile'sName.pd] I don't agree with zmoelnig in that it is not a bug. Calling functions and stacks are implementation details the patch author shouldn't need to be aware of. What the patch is doing is deleting an object. The message causing the deletion was triggered by (a message that was triggered by[...]) that object, so what? There's nothing semantically incorrect in doing that. ---------------------------------------------------------------------- Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2006-10-18 18:30 Message: Logged In: YES user_id=769033 Some comments about pd-0.40-1 from Miller's site: 1. Start pd, load gop-subpatch-self-clear-crash.pd, click bang => no crash, subpatch is cleared correctly 2. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, click bang => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211095376 (LWP 13534)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82371f8) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x82415c8, glist=0x8241200, xpix=136, ypix=139, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0808a36a in canvas_doclick (x=0x8241200, xpos=136, ypos=139, which=1, mod=0, doit=1) at g_editor.c:92 #4 0x0808b14b in canvas_mousedown (x=0x8241200, xpos=136, ypos=139, which=1, mod=0) at g_editor.c:1242 #5 0x080a79c5 in pd_typedmess (x=0x8241200, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #6 0x080a7632 in pd_typedmess (x=0x8241418, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #7 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #8 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #9 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #10 0x080b7967 in sys_pollgui () at s_inter.c:825 #11 0x080b2f53 in m_scheduler () at m_sched.c:466 #12 0x080b651a in sys_main (argc=1, argv=0xbfcbb4a4) at s_main.c:316 #13 0x080bf7cf in main (argc=136563232, argv=0x8242b00) at s_entry.c:27 3. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, close subpatch, click bang => crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210849616 (LWP 13563)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82373c0) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x823cbc0, glist=0x8237230, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0805be1a in graph_click (z=0x8237230, glist=0x8237090, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_graph.c:1052 #4 0x0808a36a in canvas_doclick (x=0x8237090, xpos=72, ypos=70, which=1, mod=0, doit=1) at g_editor.c:92 #5 0x0808b14b in canvas_mousedown (x=0x8237090, xpos=72, ypos=70, which=1, mod=0) at g_editor.c:1242 #6 0x080a79c5 in pd_typedmess (x=0x8237090, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #7 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #8 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #9 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #10 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #11 0x080b7967 in sys_pollgui () at s_inter.c:825 #12 0x080b2f53 in m_scheduler () at m_sched.c:466 #13 0x080b651a in sys_main (argc=1, argv=0xbfeee6d4) at s_main.c:316 #14 0x080bf7cf in main (argc=136541136, argv=0x823e958) at s_entry.c:27 4. Start pd, load crash-1518030.pd, click "bang" => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210677584 (LWP 13575)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x8237408) at m_obj.c:328 #2 0x080aa8eb in outlet_bang (x=0x82373d0) at m_obj.c:328 #3 0x080aa8eb in outlet_bang (x=0x823cce0) at m_obj.c:328 #4 0x080a77a1 in pd_typedmess (x=0x823cccc, s=0x8119364, argc=0, argv=0x811a950) at m_class.c:641 #5 0x080abba4 in binbuf_eval (x=0x823cc68, target=<value optimized out>, argc=1, argv=0xbfa50e8c) at m_binbuf.c:673 #6 0x0805f46d in message_click (x=0x823ccb0, xpos=91, ypos=65, shift=0, ctrl=0, alt=0) at g_text.c:300 #7 0x08063721 in text_click (z=0x823ccb0, glist=0x8237080, xpix=91, ypix=65, shift=0, alt=0, dbl=0, doit=1) at g_text.c:1065 #8 0x0808a36a in canvas_doclick (x=0x8237080, xpos=91, ypos=65, which=1, mod=0, doit=1) at g_editor.c:92 #9 0x0808b14b in canvas_mousedown (x=0x8237080, xpos=91, ypos=65, which=1, mod=0) at g_editor.c:1242 #10 0x080a79c5 in pd_typedmess (x=0x8237080, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #11 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #12 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #13 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #14 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #15 0x080b7967 in sys_pollgui () at s_inter.c:825 #16 0x080b2f53 in m_scheduler () at m_sched.c:466 #17 0x080b651a in sys_main (argc=1, argv=0xbfa52a44) at s_main.c:316 #18 0x080bf7cf in main (argc=0, argv=0x0) at s_entry.c:27 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 17:13 Message: Logged In: YES user_id=564396 the really interesting thing here, is that your patch will not crash when you only click on the [bng] once. you have to follow the steps as described. i add another patch that triggers the crash reliable and without the complicated procedure (just click it and crash it) raised priority, since crashers should be fixed. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-07-06 20:48 Message: Logged In: YES user_id=564396 this has nothing to do with GOP, therefore i renamed the bug-report. what happens: an object emits a message; the calling function is pushed to the stack; the message triggers the deletion of the object; after the message is done, the calling function (of the now deleted object) is popped back from the stack: but alas! the entire environment has changed and nothing is as it should be....stack corruption -> crash. personally i think, that this is NOT a bug in pd but rather a bug in the patch (but i am repeating myself...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_…

2 2

[ pure-data-Bugs-1518030 ] subpatch clearing itself crashes Pd
by SourceForge.net 11 Feb '07

11 Feb '07

Bugs item #1518030, was opened at 2006-07-06 11:54 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_… 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: puredata Group: v0.40.1 Status: Open Resolution: None Priority: 7 Private: No Submitted By: ClaudiusMaximus (claudiusmaximus) Assigned to: Miller Puckette (millerpuckette) Summary: subpatch clearing itself crashes Pd Initial Comment: Tested on Linux with pd-0.39-2 from Miller's site. Steps to reproduce: start pd load the patch attached to this post click the bng close the patch load the patch again click the bng => crash OR start pd load the patch open the subpatch (optionally: close the subpatch) click the bng => crash Here's a gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 27794)] pd_bang (x=0x11) at m_pd.c:269 269 m_pd.c: No such file or directory. in m_pd.c (gdb) where #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x0808a61b in outlet_bang (x=0x3) at m_obj.c:328 #2 0x080765ad in bng_bout2 (x=0x81f2790) at g_bang.c:294 #3 0x080767f6 in bng_newclick (z=0x11, glist=0x81f2338, xpix=74, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:343 #4 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #5 0x0805b557 in graph_click (z=0x81f2338, glist=0x11, xpix=74, ypix=70, shift=0, alt=0, dbl=17, doit=1) at g_graph.c:1059 #6 0x0806e907 in gobj_click (x=0x0, glist=0x11, xpix=17, ypix=17, shift=17, alt=17, dbl=17, doit=17) at g_editor.c:92 #7 0x08070a97 in canvas_doclick (x=0x81ecd08, xpos=74, ypos=70, which=1, mod=0, doit=1) at g_editor.c:1094 #8 0x0807119d in canvas_mousedown (x=0x11, xpos=0, ypos=0, which=0, mod=0) at g_editor.c:1252 #9 0x08089789 in pd_typedmess (x=0x81ecd08, s=0x0, argc=0, argv=0x80cf488) at m_class.c:728 #10 0x08089665 in pd_typedmess (x=0x81f25f8, s=0x0, argc=4, argv=0x80cf468) at m_class.c:749 #11 0x0808c32f in binbuf_eval (x=0x11, target=0x81f25f8, argc=0, argv=0x0) at m_binbuf.c:574 #12 0x08091fdf in socketreceiver_read (x=0x81ec2f0, fd=7) at s_inter.c:540 #13 0x0809180f in sys_domicrosleep (microsec=17, pollem=1) at s_inter.c:180 #14 0x08092660 in sys_pollgui () at s_inter.c:823 #15 0x0808fe5b in m_scheduler () at m_sched.c:466 #16 0x08095b1b in main (argc=17, argv=0x11) at s_entry.c:27 ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2007-02-11 13:22 Message: Logged In: YES user_id=569446 Originator: NO Hi, sistisette wrote: > There's nothing semantically incorrect in doing that. There is. You may be missing some implications of Pd's "depth first message passing" as described in the manual, chapter "2.3.2. depth first message passing": [1] "Each message sets off a tree of consequent messages." As a message is generated by an object this also means that each (message) object sets off a tree of messages. Every branch of messages has to finish at some point. If it doesn't, you have an error in your patch, that will result in an infinite message loop or "stack overflow". The manual has an example for this, but you can also just bang an [until] without stopping it to make such a stack overflow without any backwards connections. Now how does this relate to "suicide" messages, that is, messages that will result in a deletion of the object that generated the message? Lets look at the [pd x] subpatch which has a [; pd-x clear( suidice message: As soon as you click this message, it will start a "message tree of consequent messages." This message tree has to finish, and the end point here would be the clearing of the subpatch including the message box that initiated the suidice. At first look this may seem okay, but a powerful and important feature of Pd is, that an object or message can be a node for several message branches. [trigger bang float] is one example for this: Pd will first execute the tree below the right float outlet completely, and when this is finished, it will come back to the [t b f] to work on the left bang outlet's tree. With messages this also is possible, e.g. by seperating messages with a comma or semicolon: [; pd-x clear; pd-x msg 100 100 hello world(: First this message will clear [pd x] then it will evaluate the second part of the message and put a "hello world" message into [pd x]. To be able to do this Pd has to save the current branching node somehow to come back there later, when the first branch has finished. But now we have a problem, if a message tries to commit suicide and thus deletes the node that according to Pd's language rules and logic needs to be evaluated again, after the "depth first tree" has come to an end! As the node was deleted, this is impossible, the correct data flow cannot be restored and that's why these messages indeed are semantically incorrect just like infinite message loops. Of course Pd should not die if someone attempts suidide, but still these kinds of messages are illegal constructs. ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-10 19:45 Message: Logged In: YES user_id=1709568 Originator: NO Just another example that triggers the same bug (dunnow why I can't attach a file so I "transcribe" it here): [bng] | [f 0] | [find f, cut( | [s pd-thisFile'sName.pd] I don't agree with zmoelnig in that it is not a bug. Calling functions and stacks are implementation details the patch author shouldn't need to be aware of. What the patch is doing is deleting an object. The message causing the deletion was triggered by (a message that was triggered by[...]) that object, so what? There's nothing semantically incorrect in doing that. ---------------------------------------------------------------------- Comment By: ClaudiusMaximus (claudiusmaximus) Date: 2006-10-18 18:30 Message: Logged In: YES user_id=769033 Some comments about pd-0.40-1 from Miller's site: 1. Start pd, load gop-subpatch-self-clear-crash.pd, click bang => no crash, subpatch is cleared correctly 2. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, click bang => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211095376 (LWP 13534)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82371f8) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x82415c8, glist=0x8241200, xpix=136, ypix=139, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0808a36a in canvas_doclick (x=0x8241200, xpos=136, ypos=139, which=1, mod=0, doit=1) at g_editor.c:92 #4 0x0808b14b in canvas_mousedown (x=0x8241200, xpos=136, ypos=139, which=1, mod=0) at g_editor.c:1242 #5 0x080a79c5 in pd_typedmess (x=0x8241200, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #6 0x080a7632 in pd_typedmess (x=0x8241418, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #7 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #8 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #9 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #10 0x080b7967 in sys_pollgui () at s_inter.c:825 #11 0x080b2f53 in m_scheduler () at m_sched.c:466 #12 0x080b651a in sys_main (argc=1, argv=0xbfcbb4a4) at s_main.c:316 #13 0x080bf7cf in main (argc=136563232, argv=0x8242b00) at s_entry.c:27 3. Start pd, load gop-subpatch-self-clear-crash.pd, open subpatch, close subpatch, click bang => crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210849616 (LWP 13563)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x82373c0) at m_obj.c:328 #2 0x0808f101 in bng_newclick (z=0x823cbc0, glist=0x8237230, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_bang.c:294 #3 0x0805be1a in graph_click (z=0x8237230, glist=0x8237090, xpix=72, ypix=70, shift=0, alt=0, dbl=0, doit=1) at g_graph.c:1052 #4 0x0808a36a in canvas_doclick (x=0x8237090, xpos=72, ypos=70, which=1, mod=0, doit=1) at g_editor.c:92 #5 0x0808b14b in canvas_mousedown (x=0x8237090, xpos=72, ypos=70, which=1, mod=0) at g_editor.c:1242 #6 0x080a79c5 in pd_typedmess (x=0x8237090, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #7 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #8 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #9 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #10 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #11 0x080b7967 in sys_pollgui () at s_inter.c:825 #12 0x080b2f53 in m_scheduler () at m_sched.c:466 #13 0x080b651a in sys_main (argc=1, argv=0xbfeee6d4) at s_main.c:316 #14 0x080bf7cf in main (argc=136541136, argv=0x823e958) at s_entry.c:27 4. Start pd, load crash-1518030.pd, click "bang" => crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210677584 (LWP 13575)] pd_bang (x=0x11) at m_pd.c:269 269 (*(*x)->c_bangmethod)(x); (gdb) bt #0 pd_bang (x=0x11) at m_pd.c:269 #1 0x080aa8eb in outlet_bang (x=0x8237408) at m_obj.c:328 #2 0x080aa8eb in outlet_bang (x=0x82373d0) at m_obj.c:328 #3 0x080aa8eb in outlet_bang (x=0x823cce0) at m_obj.c:328 #4 0x080a77a1 in pd_typedmess (x=0x823cccc, s=0x8119364, argc=0, argv=0x811a950) at m_class.c:641 #5 0x080abba4 in binbuf_eval (x=0x823cc68, target=<value optimized out>, argc=1, argv=0xbfa50e8c) at m_binbuf.c:673 #6 0x0805f46d in message_click (x=0x823ccb0, xpos=91, ypos=65, shift=0, ctrl=0, alt=0) at g_text.c:300 #7 0x08063721 in text_click (z=0x823ccb0, glist=0x8237080, xpix=91, ypix=65, shift=0, alt=0, dbl=0, doit=1) at g_text.c:1065 #8 0x0808a36a in canvas_doclick (x=0x8237080, xpos=91, ypos=65, which=1, mod=0, doit=1) at g_editor.c:92 #9 0x0808b14b in canvas_mousedown (x=0x8237080, xpos=91, ypos=65, which=1, mod=0) at g_editor.c:1242 #10 0x080a79c5 in pd_typedmess (x=0x8237080, s=0x822ac40, argc=4, argv=0x811a928) at m_class.c:728 #11 0x080a7632 in pd_typedmess (x=0x823ca28, s=0x822ac40, argc=<value optimized out>, argv=0x811a928) at m_class.c:749 #12 0x080abba4 in binbuf_eval (x=0x82366e0, target=<value optimized out>, argc=0, argv=0x0) at m_binbuf.c:673 #13 0x080b94be in socketreceiver_read (x=0x8236700, fd=8) at s_inter.c:540 #14 0x080b693e in sys_domicrosleep (microsec=<value optimized out>, pollem=<value optimized out>) at s_inter.c:180 #15 0x080b7967 in sys_pollgui () at s_inter.c:825 #16 0x080b2f53 in m_scheduler () at m_sched.c:466 #17 0x080b651a in sys_main (argc=1, argv=0xbfa52a44) at s_main.c:316 #18 0x080bf7cf in main (argc=0, argv=0x0) at s_entry.c:27 ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-10-10 17:13 Message: Logged In: YES user_id=564396 the really interesting thing here, is that your patch will not crash when you only click on the [bng] once. you have to follow the steps as described. i add another patch that triggers the crash reliable and without the complicated procedure (just click it and crash it) raised priority, since crashers should be fixed. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2006-07-06 20:48 Message: Logged In: YES user_id=564396 this has nothing to do with GOP, therefore i renamed the bug-report. what happens: an object emits a message; the calling function is pushed to the stack; the message triggers the deletion of the object; after the message is done, the calling function (of the now deleted object) is popped back from the stack: but alas! the entire environment has changed and nothing is as it should be....stack corruption -> crash. personally i think, that this is NOT a bug in pd but rather a bug in the patch (but i am repeating myself...) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1518030&group_…

1 0

[ pure-data-Bugs-1655670 ] misterious crashes when scripting
by SourceForge.net 10 Feb '07

10 Feb '07

Bugs item #1655670, was opened at 2007-02-09 02:08 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_… 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: puredata Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: misterious crashes when scripting Initial Comment: Hi, I'm sorry I can't be more specific. The attached patch makes PD crash. Look at the patch, it has a lot of comments. I have reduced it to the minimum that I could. I use messages to dinamically create and delete an object within a (sub)subpatch and connect it. I pass a float "through" the subpatch when the dinamically created objects and connections are made so that it can pass through. When doing a single iteration, that works. However, for some reason, if I put it into a loop (by feeding back the output to the input) it crashes. Note that the loop is not infinite, since I have a decrement and a condition to stop it after a number of iterations. It crashes even with a couple of iterations. ---------------------------------------------------------------------- >Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-10 16:37 Message: Logged In: YES user_id=1709568 Originator: YES Thank you fbar, this explains better where the bug is and helps me isolating it in the following patch, which I attach as testbug4b.pd and which I reproduce here as it is very simple: [bng] | [f] | [find f, cut( | [s pd-testbug4b.pd] (assuming the file is saved as testbug4b.pd) However, I think this still is a bug. 1) First, because whenever a program crashes it is a bug, no matter how incorrect the input (in this case the patch). 2) Secondly, because I don't see what is semantically wrong about deleting the [f] even if the message that deletes it has been originated by itself. That is an implementation issue. Let's look at the flux of data, or messages. [f] outputs a message that is a float. This message hits the message box and causes it to output two messages: -a "find f", which reaches the [s], is sent to the canvas, and causes the [f] to be selected -a "cut", which reaches the [s], is sent to the canvas, and causes the [f] to be deleted. ...so what? If, internally, the flux of data is tracked somewhere "inside" the object that originates it, it is a matter of implementation that the patch author need not care about. And that is an implementation that doesn't completely take into account the possibility that objects may dynamically be deleted. File Added: testbug4b.pd ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-02-10 01:21 Message: Logged In: YES user_id=569446 Originator: NO This actually is a "I shoot myself in the foot to commit suicide" bug in the patch. ;) What is happening here: After triggering the "30" the [t f f b] in [pd one] will first delete the [f] in [pd two] and then recreate it. This is okay. Then the 30 will be sent from the middle outlet of the [t f f b] and open the spigot. From the left outlet of [t f f b] it will then be decremented to 29 and go into [pd two] where it is passed through the [f]. This moment is important so lets mark it with <crash-reason>. The 29 will then leave [pd two] and after that leave [pd one] as well, go through the outside [t f f] and enter [pd one] again. Now as it reaches [t f f b] in [pd one] again, where it will again first initiate the bang that cuts the [f] in [pd two]. But now the problem occurs: In the past at time <crash-reason> the [f] in [pd two] was, what was triggering the second time, the [f] in [pd two] should be deleted, so to Pd this is a case of suicide: The [f] object is trying to delete itself and that's illegal. It's not a bug in Pd - although Pd shouldn't crash - it's more a bug in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…

2 1

[ pure-data-Bugs-1655670 ] misterious crashes when scripting
by SourceForge.net 10 Feb '07

10 Feb '07

Bugs item #1655670, was opened at 2007-02-09 02:08 Message generated for change (Comment added) made by fbar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_… 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: puredata Group: v0.40.2 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: misterious crashes when scripting Initial Comment: Hi, I'm sorry I can't be more specific. The attached patch makes PD crash. Look at the patch, it has a lot of comments. I have reduced it to the minimum that I could. I use messages to dinamically create and delete an object within a (sub)subpatch and connect it. I pass a float "through" the subpatch when the dinamically created objects and connections are made so that it can pass through. When doing a single iteration, that works. However, for some reason, if I put it into a loop (by feeding back the output to the input) it crashes. Note that the loop is not infinite, since I have a decrement and a condition to stop it after a number of iterations. It crashes even with a couple of iterations. ---------------------------------------------------------------------- >Comment By: Frank Barknecht (fbar) Date: 2007-02-10 18:49 Message: Logged In: YES user_id=569446 Originator: NO Hi, I'm closing this bug as it's in fact a duplicate of bug number 1518030. 1518030 has a clearer example to illustrate the patch, so I'd rather keep that one. Ciao -- Frank ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-02-10 16:37 Message: Logged In: YES user_id=1709568 Originator: YES Thank you fbar, this explains better where the bug is and helps me isolating it in the following patch, which I attach as testbug4b.pd and which I reproduce here as it is very simple: [bng] | [f] | [find f, cut( | [s pd-testbug4b.pd] (assuming the file is saved as testbug4b.pd) However, I think this still is a bug. 1) First, because whenever a program crashes it is a bug, no matter how incorrect the input (in this case the patch). 2) Secondly, because I don't see what is semantically wrong about deleting the [f] even if the message that deletes it has been originated by itself. That is an implementation issue. Let's look at the flux of data, or messages. [f] outputs a message that is a float. This message hits the message box and causes it to output two messages: -a "find f", which reaches the [s], is sent to the canvas, and causes the [f] to be selected -a "cut", which reaches the [s], is sent to the canvas, and causes the [f] to be deleted. ...so what? If, internally, the flux of data is tracked somewhere "inside" the object that originates it, it is a matter of implementation that the patch author need not care about. And that is an implementation that doesn't completely take into account the possibility that objects may dynamically be deleted. File Added: testbug4b.pd ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-02-10 01:21 Message: Logged In: YES user_id=569446 Originator: NO This actually is a "I shoot myself in the foot to commit suicide" bug in the patch. ;) What is happening here: After triggering the "30" the [t f f b] in [pd one] will first delete the [f] in [pd two] and then recreate it. This is okay. Then the 30 will be sent from the middle outlet of the [t f f b] and open the spigot. From the left outlet of [t f f b] it will then be decremented to 29 and go into [pd two] where it is passed through the [f]. This moment is important so lets mark it with <crash-reason>. The 29 will then leave [pd two] and after that leave [pd one] as well, go through the outside [t f f] and enter [pd one] again. Now as it reaches [t f f b] in [pd one] again, where it will again first initiate the bang that cuts the [f] in [pd two]. But now the problem occurs: In the past at time <crash-reason> the [f] in [pd two] was, what was triggering the second time, the [f] in [pd two] should be deleted, so to Pd this is a case of suicide: The [f] object is trying to delete itself and that's illegal. It's not a bug in Pd - although Pd shouldn't crash - it's more a bug in the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…

1 0

[ pure-data-Bugs-1655670 ] misterious crashes when scripting
by SourceForge.net 10 Feb '07

10 Feb '07

1 0

[ pure-data-Patches-1656382 ] OSCx - assign TTL only for multicast groups
by SourceForge.net 09 Feb '07

09 Feb '07

Patches item #1656382, was opened at 2007-02-09 15:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1656382&group_… 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: externals Group: bugfix Status: Open Resolution: None Priority: 5 Private: No Submitted By: Stephen Sinclair (radarsat1) Assigned to: Nobody/Anonymous (nobody) Summary: OSCx - assign TTL only for multicast groups Initial Comment: I realized that in my previous changes to OSCx, I caused sendOSC to set the TTL value for any UDP connection. This could cause unexpected default behaviour, whether using multicast or not, when trying to use OSC on a long network connection, outside of a local subnet, such as between continents. This patch changes the behaviour so that it only sets TTL for actual multicast IP addresses. It also rejects requests to create connections on the range of multicast addresses reserved for routing information. (This is described here: http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/index.html) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1656382&group_…

1 0

[ pure-data-Bugs-1655670 ] misterious crashes when scripting
by SourceForge.net 09 Feb '07

09 Feb '07

Bugs item #1655670, was opened at 2007-02-09 02:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_… 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: puredata Group: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: misterious crashes when scripting Initial Comment: Hi, I'm sorry I can't be more specific. The attached patch makes PD crash. Look at the patch, it has a lot of comments. I have reduced it to the minimum that I could. I use messages to dinamically create and delete an object within a (sub)subpatch and connect it. I pass a float "through" the subpatch when the dinamically created objects and connections are made so that it can pass through. When doing a single iteration, that works. However, for some reason, if I put it into a loop (by feeding back the output to the input) it crashes. Note that the loop is not infinite, since I have a decrement and a condition to stop it after a number of iterations. It crashes even with a couple of iterations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655670&group_…

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev February 2007