[PD-dev] [ pure-data-Bugs-1518030 ] GOP subpatch clearing itself crashes Pd

[Hans-Christoph Steiner]

On Jul 6, 2006, at 2:27 PM, zmoelnig at iem.at wrote:

> Zitat von "SourceForge.net" <noreply at 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