I've been trying to track down a bug which crashes pd when switching song patches in my performance system. I first recall seeing this with 0.47-1 and never had a problem before with Pd-extended. It's a showstopper and keeping me from using PdParty for what I built it for.
Basically, I have a main performance patch for audio io, playlist management, transport control, and OSC communication. Songs are separate patches that are opened and closed when running through the playlist using the "pd open $file $dir" and "pd-PatchName.pd menu close 1" messages. The song patches communicate with the performance patch via send and receive objects.
The problem comes where sometimes closing a patch leads to a crash. I've tested numerous approaches and opening is not a problem, only the close message. Digging through with the debugger shows the crash generally happens in pd_typedmess and it seems as though messages being sent to the global send objects between the patches are being processed in a patch even after it was just closed which ends in a BAD_ACCESS. At least that's as far as I've been able to figure things out. I can provide backtraces, etc.
I'm hoping to figure this out as I've been wanting to develop for and use my newer system but this is really killing any chance so far.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Instead of closing it from the main patch, did you try asking the song patch to close itself after a small delay (10ms)? And making sure that no communication occurs between them at that moment.
Other test: dynamic patching in a subpatch of the main patch (maybe worse...)
Of course a bug fix would be better...
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-27 13:02 GMT+02:00 Dan Wilcox danomatika@gmail.com:
I've been trying to track down a bug which crashes pd when switching song patches in my performance system. I first recall seeing this with 0.47-1 and never had a problem before with Pd-extended. It's a showstopper and keeping me from using PdParty for what I built it for.
Basically, I have a main performance patch for audio io, playlist management, transport control, and OSC communication. Songs are separate patches that are opened and closed when running through the playlist using the "pd open $file $dir" and "pd-PatchName.pd menu close 1" messages. The song patches communicate with the performance patch via send and receive objects.
The problem comes where sometimes closing a patch leads to a crash. I've tested numerous approaches and opening is not a problem, only the close message. Digging through with the debugger shows the crash generally happens in pd_typedmess and it seems as though messages being sent to the global send objects between the patches are being processed in a patch even after it was just closed which ends in a BAD_ACCESS. At least that's as far as I've been able to figure things out. I can provide backtraces, etc.
I'm hoping to figure this out as I've been wanting to develop for and use my newer system but this is really killing any chance so far.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I just found out that if 2 instances of the same file are opened, sending a "pd-PatchName.pd menuclose" crashes Pd. I don't know if it is related to your problem.
If only one instance is opened, crash happens pretty rarely, but it happens...
see attached test.
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-27 16:17 GMT+02:00 Antoine Rousseau antoine@metalu.net:
Instead of closing it from the main patch, did you try asking the song patch to close itself after a small delay (10ms)? And making sure that no communication occurs between them at that moment.
Other test: dynamic patching in a subpatch of the main patch (maybe worse...)
Of course a bug fix would be better...
Antoine Rousseau http://www.metalu.net http://metalu.net __ htt p://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-27 13:02 GMT+02:00 Dan Wilcox danomatika@gmail.com:
I've been trying to track down a bug which crashes pd when switching song patches in my performance system. I first recall seeing this with 0.47-1 and never had a problem before with Pd-extended. It's a showstopper and keeping me from using PdParty for what I built it for.
Basically, I have a main performance patch for audio io, playlist management, transport control, and OSC communication. Songs are separate patches that are opened and closed when running through the playlist using the "pd open $file $dir" and "pd-PatchName.pd menu close 1" messages. The song patches communicate with the performance patch via send and receive objects.
The problem comes where sometimes closing a patch leads to a crash. I've tested numerous approaches and opening is not a problem, only the close message. Digging through with the debugger shows the crash generally happens in pd_typedmess and it seems as though messages being sent to the global send objects between the patches are being processed in a patch even after it was just closed which ends in a BAD_ACCESS. At least that's as far as I've been able to figure things out. I can provide backtraces, etc.
I'm hoping to figure this out as I've been wanting to develop for and use my newer system but this is really killing any chance so far.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 09/27/2017 04:51 PM, Antoine Rousseau wrote:
I just found out that if 2 instances of the same file are opened, sending a "pd-PatchName.pd menuclose" crashes Pd. I don't know if it is related to your problem.
iirc that has been reported on the tracker (on sf, i think) a while ago.
the problem is basically that you are modifying a linked list while iterating over it (which is forbidden in a lot of high level languages for a good reason).
afaict, iemguts' [canvasdelete] object provides a sane way to delete open patches (or instantiated abstractions). (but it's GPLed, so it might be of limited use if your target platform is libpd/iOS)
cmx IOhannes
modifying a linked list while iterating over it
yes. And if (for this name) there is only one receiver (the one which is deleted when the message is received), then the end of the list is reached before trying to access next element, so it *should* not crash.
Strangely, trying to 'menuclose' self top-level patch (through [namecanvas]) crashes Pd, excepting when the patch isn't yet saved (newly created one).
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.
Antoine Rousseau http://www.metalu.net http://metalu.net __ http://www.metaluachahuter.com/ http://www.metaluachahuter.com/compagnies/al1-ant1/
2017-09-27 22:38 GMT+02:00 IOhannes m zmölnig zmoelnig@iem.at:
On 09/27/2017 04:51 PM, Antoine Rousseau wrote:
I just found out that if 2 instances of the same file are opened,
sending a
"pd-PatchName.pd menuclose" crashes Pd. I don't know if it is related to your problem.
iirc that has been reported on the tracker (on sf, i think) a while ago.
the problem is basically that you are modifying a linked list while iterating over it (which is forbidden in a lot of high level languages for a good reason).
afaict, iemguts' [canvasdelete] object provides a sane way to delete open patches (or instantiated abstractions). (but it's GPLed, so it might be of limited use if your target platform is libpd/iOS)
cmx IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Antoine Rousseau -
Dan Wilcox -
IOhannes m zmölnig