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

IOhannes m zmoelnig zmoelnig at iem.at
Mon Feb 12 09:19:47 CET 2007


Frank Barknecht wrote:
> Hallo,
> Thomas Grill hat gesagt: // Thomas Grill wrote:
> 
>> Am 11.02.2007 um 21:50 schrieb Tim Blechmann:
>>
>>>> Well, then how should Pd solve the logical pitfalls in your opinion?
>>> mark the object as deletable, if the messaging is happening, wait for
>>> the object to return from the message function, then it can be safely
>>> deleted.
>> exactly, but the object should not process any further messages when  
>> the mark is set.
>> I recently encountered the same situation, and by debugging i found  
>> that the crash happens while traversing the outlets to see if the  
>> message should be sent to other objects. It would be easy to check  
>> for such a mark there.
> 
> I'm wondering: There are other, less obvious cases of suicide that
> currently lead to a crash. I encountered this when trying to close the
> Gem-window by watching for the <Esc> key with [gemkeyname] connected
> to [0, destroy(--[gemwin]. This also crashes Pd and according to
> IOhannes for a similar reason. Inserting a [delay] in between this
> will fix it as well. However here not a single object is deleted.
> Which object should be "marked" here?
> 

btw, this has been fixed in Gem some time ago (at least it should!)
the way it is done, is by entering a "deletable" state, which will be
executed asap (but after stack execution), which is basically after a
[del 0] (sounds familiar...)

i am not totally happy with this solution because of the following
problem: [destroy, create(
what should happen here? (well the answer is trivial; but it is not so
trivial any more, if we depend on execution order)
2 solutions come to my mind:
- since [destroy( is delayed, [create( has to be delayed too; this would
lead us to hell...
- since the window is still existing when we call [create(, no new
window is created (but the destruction is canceled); this is NOT what we
have told the interpreter to do; destroying and re-creating a context is
NOT the same as not touching it at all.

i think the problem is not a big one, if we consider only the single
case of destroying the Gem-window. (this could always be seen as a
"special" case)

however, i don't think it is a valid assumption for pd itself.
in this case, i would highly prefer an error-message to the console (an
"exception") and no destruction at all.
(since usually you have more complex settings when doing dynamic
patching, e.g. [clear, obj 0 0 inlet, obj 0 100 outlet, connect 0 0 1 0( )

i think i have said this already, the last time this issue came up.

mfg.asd
IOhannes






More information about the Pd-dev mailing list