I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object...
The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.
I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.)
Maybe this is something fixed in extended?
On Sep 28, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
That said, I think that @Dan could use dynamic patching; I've just successfully tested creating/destroying abstractions every 5 millis, while the abstractions were forwarding a value updated every millisecond from master patch, without any crash.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I don't think closing a patch using its $0 could fix this: "if a message sent to a channel has the effect of changing immediately the number of receivers for this channel, then Pd is likely to crash." It would also be the case if sending to a $0 related channel I think ; while clearing a subpatch (aka dynamic patching) doesn't lead to this condition.
OTOH I really don't know why it seemed to be different in Pd-extended or older vanillas...
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-29 10:26 GMT+02:00 Dan Wilcox danomatika@gmail.com:
I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object...
The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.
I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.)
Maybe this is something fixed in extended?
On Sep 28, 2017, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
That said, I think that @Dan could use dynamic patching; I've just successfully tested creating/destroying abstractions every 5 millis, while the abstractions were forwarding a value updated every millisecond from master patch, without any crash.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
IOhannes, et al, any tips on where to look to fix this?
On Sep 29, 2017, at 11:47 AM, Antoine Rousseau antoine@metalu.net wrote:
I don't think closing a patch using its $0 could fix this: "if a message sent to a channel has the effect of changing immediately the number of receivers for this channel, then Pd is likely to crash." It would also be the case if sending to a $0 related channel I think ; while clearing a subpatch (aka dynamic patching) doesn't lead to this condition.
OTOH I really don't know why it seemed to be different in Pd-extended or older vanillas...
Antoine Rousseau http://www.metalu.net http://metalu.net/ __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-29 10:26 GMT+02:00 Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com>: I'm not really a huge fan of dynamics patching for this as simply open and close seems so much cleaner. That being said, I wish there was a vanilla way to close an open patch using it's $0, etc. That's more of a matter for my suggestions for a more general canvas info etc object...
The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.
I haven't experienced this with Pd-extended either and have played many shows, including the one in Nov at the Pd-con. It's only with trying to adapt this setup to vanilla that I'm running into things. (Yes, I've still been using extended for some older sets but am transitioning now.)
Maybe this is something fixed in extended?
On Sep 28, 2017, at 12:00 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
That said, I think that @Dan could use dynamic patching; I've just successfully tested creating/destroying abstractions every 5 millis, while the abstractions were forwarding a value updated every millisecond from master patch, without any crash.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 10/22/2017 04:27 PM, Dan Wilcox wrote:
IOhannes, et al, any tips on where to look to fix this?
gdb. also check [1300] for a simple fix. (i thought i had put more triaging information into that bug-report but apparently not; most likely becaues it was easy enough to do then...)
gfasmr IOhannes
The crashes are almost always happening in m_class.c pd_typedmess():
1) when accessing x via t_class *c = *x or 2) when accessing the typemethod in m->me_name
I've managed to isolate the 1) by:
* setting the pointer value to 0 at the end of m_pd.c pd_free() with memset(&x, 0, sizeof(x)); * and checking if x is NULL and returning at the beginning of pd_typedmess()
As suggested before, this seems to indicate that the menuclose frees the canvas object while pd_typedmess() is checking for receive objects. I have no issue opening & closing patches without receive objects.
On Oct 22, 2017, at 4:27 PM, Dan Wilcox danomatika@gmail.com wrote:
IOhannes, et al, any tips on where to look to fix this?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On 09/29/2017 10:26 AM, Dan Wilcox wrote:
The funny thing is that I never experienced this issue before, way back to the original system running in 2006. I think the difference is the hardware was slower, so the list might have been traversed before the patch was closed whereas now the patch closes more quickly while the message is mid-list. Or vice versa.
afaict everyhing happening here is fully deterministic (that is: there's no race condition involved), leading to "undefined behaviour". UB means that it *can* crash, but it might as well not.
there#s a couple of other reasons why the problem might be exposed now (and not in the olden days): - modern compilers do better optimization - fixing memory bugs (e.g. memleaks) changes the memory layout (allowing re-use of previously-not-unallocated memory)
gmadsr IOhannes
-
Antoine Rousseau -
Dan Wilcox -
IOhannes m zmölnig