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