Zitat von "SourceForge.net" noreply@sourceforge.net:
Summary: GOP 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
funny how things turn up at the same time. this has been mentioned on the gem-dev just 1.5 weeks ago: http://lists.puredata.info/pipermail/gem-dev/2006-06/002046.html
the problem is totally unrelated to gop (though the title suggests it)
the simplest example to trigger this, is to create asubpatch (let's assume [pd subpatch]) with just an [inlet] and an [outlet] connected (a [nop]). connect the outlet to a [; pd-subpatch clear( message and send a [bang( to the inlet.
the basic problem is, that an objects outlet triggers the destruction of the object, thus causing stack corruption.
personally, i still think that this is NOT a bug with pd but a bug in the patch.
mfg.asdr IOhannes
On Jul 6, 2006, at 2:27 PM, zmoelnig@iem.at wrote:
Zitat von "SourceForge.net" noreply@sourceforge.net:
Summary: GOP 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
funny how things turn up at the same time. this has been mentioned on the gem-dev just 1.5 weeks ago: http://lists.puredata.info/pipermail/gem-dev/2006-06/002046.html
the problem is totally unrelated to gop (though the title suggests it)
the simplest example to trigger this, is to create asubpatch (let's assume [pd subpatch]) with just an [inlet] and an [outlet] connected (a [nop]). connect the outlet to a [; pd-subpatch clear( message and send a [bang( to the inlet.
the basic problem is, that an objects outlet triggers the destruction of the object, thus causing stack corruption.
personally, i still think that this is NOT a bug with pd but a bug in the patch.
Yeah, its probably not fixable without limiting flexibility. Any good programming language will let you crash things in certain ways (fork bomb, infinite loops, rm -rf /, etc.). Exception handling would be a nice solution to this, but that's not an easy one to implement.
.hc
On Thu, 6 Jul 2006, Hans-Christoph Steiner wrote:
personally, i still think that this is NOT a bug with pd but a bug in the patch.
Yeah, its probably not fixable without limiting flexibility. Any good programming language will let you crash things in certain ways (fork bomb, infinite loops, rm -rf /, etc.). Exception handling would be a nice solution to this, but that's not an easy one to implement.
Hi,
I think the case should be investigated. A segmentation fault in Pd is a bug and should be avoided. What about delaying the clear message to the canvas ?
Günter
On Jul 7, 2006, at 8:25 AM, geiger wrote:
On Thu, 6 Jul 2006, Hans-Christoph Steiner wrote:
personally, i still think that this is NOT a bug with pd but a bug in the patch.
Yeah, its probably not fixable without limiting flexibility. Any good programming language will let you crash things in certain ways (fork bomb, infinite loops, rm -rf /, etc.). Exception handling would be a nice solution to this, but that's not an easy one to implement.
Hi,
I think the case should be investigated. A segmentation fault in Pd is a bug and should be avoided. What about delaying the clear message to the canvas ?
If it can be fixed without loss of features, even better. A delay sounds plausible, tho I have no specific info.
.hc
------------------------------------------------------------------------
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
On Fri, 7 Jul 2006, geiger wrote:
I think the case should be investigated. A segmentation fault in Pd is a bug and should be avoided.
Yes, and Pd already has several mechanisms for avoiding segfaults, so there is precedent. In particular, it has t_gfxstub and t_gpointer, which are two kinds of weak pointers. (there is also t_gstub, which is a kind of reference-counting pointer, but I'm not sure about categorizing it as a "segfault prevention device").
BTW, I have this problem with t_gpointers ... I want to do this,
[gemhead] | [t b a] | | [list] | [list trim] | [square]
Which a stub in which I'd insert a [until] so as to bang the [list] repeatedly. Note that this would all happen before the control is returned to [gemhead] (and I'm not destroying the gemwin either), so the gemstate message would still be valid. However, [list] wants to copy A_POINTER args as t_gpointer structs, whereas all A_POINTERs in GEM/GF/PDP are fake, so i get "consistency errors" and I suppose crashes would be possible too. How should I deal with this?
BTW someone had an alternate way of doing this using other objects, but I don't recall how.
I need this because of [GEMglVertex3f] or whatever the name is.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
I don't have any idea how to do that... maybe the "any" object will work. It's of course incorrect for Gem to use A_POINTER this way -- I'd suggest changing it so that the gemhead temporarily binds it to a symbol (#gem?) so that 'square' etc can get a reference back to it.
cheers Miller
On Tue, Jul 11, 2006 at 01:51:58PM -0400, Mathieu Bouchard wrote:
On Fri, 7 Jul 2006, geiger wrote:
I think the case should be investigated. A segmentation fault in Pd is a bug and should be avoided.
Yes, and Pd already has several mechanisms for avoiding segfaults, so there is precedent. In particular, it has t_gfxstub and t_gpointer, which are two kinds of weak pointers. (there is also t_gstub, which is a kind of reference-counting pointer, but I'm not sure about categorizing it as a "segfault prevention device").
BTW, I have this problem with t_gpointers ... I want to do this,
[gemhead] | [t b a] | | [list] | [list trim] | [square]
Which a stub in which I'd insert a [until] so as to bang the [list] repeatedly. Note that this would all happen before the control is returned to [gemhead] (and I'm not destroying the gemwin either), so the gemstate message would still be valid. However, [list] wants to copy A_POINTER args as t_gpointer structs, whereas all A_POINTERs in GEM/GF/PDP are fake, so i get "consistency errors" and I suppose crashes would be possible too. How should I deal with this?
BTW someone had an alternate way of doing this using other objects, but I don't recall how.
I need this because of [GEMglVertex3f] or whatever the name is.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montr?al QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 11 Jul 2006, Miller Puckette wrote:
I don't have any idea how to do that... maybe the "any" object will work. It's of course incorrect for Gem to use A_POINTER this way -- I'd suggest changing it so that the gemhead temporarily binds it to a symbol (#gem?) so that 'square' etc can get a reference back to it.
How do you bind a non-t_pd to a symbol ? (or else, gemstate could become a t_pd... just like t_outconnect is now a t_gobj in a certain branch of pd)
What would you suggest for the case of a certain other video plugin in which any number of fake-A_POINTERs are being used at once, instead of just one? I'm talking about GridFlow.
Another solution is to go back to using A_FLOAT as I was doing before. I dropped using a pair A_FLOAT when I implemented 64-bit support. If I go back to A_FLOAT it will be using 3 A_FLOAT.
BTW I just had a look at PDP again, and PDP doesn't use A_POINTER. It seems to be numbering all buffers using small integers, and passing those around as a single A_FLOAT. That's also the solution implemented by the little-known MAPOD video plugin. That could be an option for GridFlow.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 11 Jul 2006, Mathieu Bouchard wrote:
Another solution is to go back to using A_FLOAT as I was doing before. I dropped using a pair A_FLOAT when I implemented 64-bit support. If I go back to A_FLOAT it will be using 3 A_FLOAT.
I mean that I'm only using the nonnegative integer subset of float. That's 24 bits, from 0 to 16777215. A 32-bit pointer can fit in two such ints, but a 64-bit pointer needs a third such int.
(actually, today's 64-bit pointers use less than 48 bits, so they could fit in two floats with some special tricks, but it's not even worth thinking about it.)
Not limiting myself to integer floats, though, I could simply cast a void** to a float* and call it an array of 2 floats. I don't know why I didn't do it that way. Superstitions, prolly.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:
I don't have any idea how to do that... maybe the "any" object will work.
[any] will work for that and it's a common trick to do something like this:
[gemhead] | [bang] | [1 0 0, 0 1 0, 0 0 1( | [t b a] | | | [s SQUARE-COORD] | | [gemhead 45] <== smaller than gemhead above | | [any] [r SQUARE-COORD] | | (unpack omitted) [translateXYZ] | [square 0.2]
This will draw 3 squares at 1 0 0, 0 1 0 and 0 0 1. though I just learned that in this case, the [any] also can be replaced with the second [gemhead 45] altogether.
Btw. I tried to use [list] in this fashion directly after it was introduced to replace [any] here and found that it doesn't work.
Ciao
On Tue, Jul 11, 2006 at 01:51:58PM -0400, Mathieu Bouchard wrote:
On Fri, 7 Jul 2006, geiger wrote:
BTW, I have this problem with t_gpointers ... I want to do this,
[gemhead] | [t b a] | | [list] | [list trim] | [square]
get "consistency errors" and I suppose crashes would be possible too. How
This kind of action has always given me crashes.
I need this because of [GEMglVertex3f] or whatever the name is.
What about using [repeat] from zexy? See this thread, especially Frank's replies: http://lists.puredata.info/pipermail/pd-list/2006-06/039049.html
There are built in Gem externals which are probably more efficient than a bunch of [GEMglVertex3f].
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
hi
geiger wrote:
Hi,
I think the case should be investigated. A segmentation fault in Pd is a bug and should be avoided. What about delaying the clear message to the canvas ?
hmm, introducing a delay will somewhat break the execution order:
[clear, obj 100 100 f( | [s pd-subpatch]
if "clear" was autodelayed, then it would be executed _after_ the creation of the [f] object, which is most likely NOT what was intended. (we could also autodelay the "obj 100 100 f" message, but that kind of leads us to hell)
i would favour a dropping of the "clear" message if it would lead to a crash and a warning on the console...
mfg.asdr. IOhannes
GÃŒnter
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Thu, 6 Jul 2006, Hans-Christoph Steiner wrote:
Yeah, its probably not fixable without limiting flexibility. Any good programming language will let you crash things in certain ways (fork bomb, infinite loops, rm -rf /, etc.). Exception handling would be a nice solution to this, but that's not an easy one to implement.
Yes. This is because externs (and interns) aren't built in an interruptible fashion. What Pd needs for that, is a macro-driven block like:
TRY { ... } ENSURE { ... }
Where a TRY section may be interrupted anytime (e.g. by a watchdog timeout) and the ENSURE section is always run after the TRY section even when it was interrupted. The ENSURE section does cleanup in order to prevent leaks and possible crashes/inconsistencies. e.g.:
void myobject_mymethod(myobject *self, t_symbol *phun) { /* you may assume self->foo is 0 at this point */ TRY { self->foo = malloc(666); outlet_symbol(self->out,phun); (stuff goes here involving self->foo) } ENSURE { if (self->foo) {free(self->foo); self->foo=0;} } }
The TRY {} ENSURE {} statement would be implemented using standard (though scary) C functions like setjmp() and longjmp(), which handle nonlocal returns.
Also other handling mechanisms like CATCH and RETRY and such can be thought of and implemented.
API versioning can be used to separate object-classes that were written with exceptions in mind, from those that weren't.
A problem with watchdog timeouts is that it's difficult and nonportable for a UNIX signal-handler to influence the normal execution of the thread it runs on top of. As a result, to be portable, those timeouts have to be implemented in a more explicit way than we might want to, and then it wouldn't catch all possible timeouts. (e.g. not while(1){})
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 11 Jul 2006, Mathieu Bouchard wrote:
A problem with watchdog timeouts is that it's difficult and nonportable for a UNIX signal-handler to influence the normal execution of the thread it runs on top of. As a result, to be portable, those timeouts have to be implemented in a more explicit way than we might want to, and then it wouldn't catch all possible timeouts. (e.g. not while(1){})
What I mean is that there would be a number of checkpoints, e.g. every time a Pd message is sent (by modifying m_pd.c and/or m_obj.c), and such checkpoints would look at a global variable indicating timeout, which is settable from a UNIX/POSIX signal-handler.
Exceptions that don't involve timeouts won't have this problem, but then, for that case, I also had a concept of non-interrupting exception which would be much easier to implement in Pd and would fit more with the style of Pd. It only consists in redirecting pd_error() and error() calls.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
the simplest example to trigger this, is to create asubpatch (let's assume [pd subpatch]) with just an [inlet] and an [outlet] connected (a [nop]). connect the outlet to a [; pd-subpatch clear( message and send a [bang( to the inlet.
Attached is another version using [namecanvas] ... and showing, why this object is deprecated, plus a version, that doesn't even need [namecanvas] to crash. I tried to strip this down to a single message box, but unfortunatly it didn't work...
Ciao
On Jul 6, 2006, at 6:23 PM, Frank Barknecht wrote:
Hallo, zmoelnig@iem.at hat gesagt: // zmoelnig@iem.at wrote:
the simplest example to trigger this, is to create asubpatch (let's assume [pd subpatch]) with just an [inlet] and an [outlet] connected (a [nop]). connect the outlet to a [; pd-subpatch clear( message and send a [bang( to the inlet.
Attached is another version using [namecanvas] ... and showing, why this object is deprecated, plus a version, that doesn't even need [namecanvas] to crash. I tried to strip this down to a single message box, but unfortunatly it didn't work...
As discussed previously, [namecanvas] should not be deprecated because it provides key functionality that nothing else does (AFAIK). You can use [namecanvas] to send messages to individual instances of an object written in Pd.
.hc
------------------------------------------------------------------------
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
On Fri, 7 Jul 2006, Frank Barknecht wrote:
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated.
Saying "pdrc is deprecated" is also deprecated.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated.
Saying "pdrc is deprecated" is also deprecated.
as long as pd isn't deprecated ... :)
t
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
The aim of education is the knowledge, not of facts, but of values William S. Burroughs
On Tue Jul 11, 2006 at 09:55:36PM +0200, Tim Blechmann wrote:
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated.
Saying "pdrc is deprecated" is also deprecated.
as long as pd isn't deprecated ... :)
Pd Not Presently Deprecated ... :)
t
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
The aim of education is the knowledge, not of facts, but of values William S. Burroughs
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2006-07-11 at 20:08 +0000, carmen wrote:
Pd Not Presently Deprecated ... :)
:D
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Silence is only frightening to people who are compulsively verbalizing. William S. Burroughs
On Tue, 11 Jul 2006, Tim Blechmann wrote:
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated. Saying "pdrc is deprecated" is also deprecated.
as long as pd isn't deprecated ... :)
what do you mean? don't you wish it'd be deprecated?
http://klingt.org/pipermail/pnpd-dev/2006-July/date.html http://artengine.ca/pipermail/dataflow/2006-July/000055.html
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, Jul 11, 2006 at 04:20:44PM -0400, Mathieu Bouchard wrote:
On Tue, 11 Jul 2006, Tim Blechmann wrote:
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated. Saying "pdrc is deprecated" is also deprecated.
as long as pd isn't deprecated ... :)
what do you mean? don't you wish it'd be deprecated?
http://klingt.org/pipermail/pnpd-dev/2006-July/date.html http://artengine.ca/pipermail/dataflow/2006-July/000055.html
The world of Free software would be much sadder if there was only one browser, or one word processor, or one mailer daemon.
Best,
Chris.
------------------- chris@mccormick.cx http://mccormick.cx
On Tue, 2006-07-11 at 16:20 -0400, Mathieu Bouchard wrote:
On Tue, 11 Jul 2006, Tim Blechmann wrote:
Attached is another version using [namecanvas] ... and showing, why this object is deprecated,
Saying "[namecanvas] is deprecated" is deprecated. Saying "pdrc is deprecated" is also deprecated.
as long as pd isn't deprecated ... :)
what do you mean? don't you wish it'd be deprecated?
i really don't care, if pd is deprecated or not ... although sometimes i have the feeling, that it is
cheers ... tim
-- tim@klingt.org ICQ: 96771783 http://www.mokabar.tk
Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac
-
carmen -
Chris McCormick -
Frank Barknecht -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Miller Puckette -
Tim Blechmann -
zmoelnig＠iem.at