Well, I'll let you all confirm that before I truly say so : ).
But, by sheer luck, I'm hoping I've found the memory-corruption bug causing my pd abstractions to be so unstable (as I've lamented quite a few times).
Hopefully this is narrowed down enough to be useful Miller! (I'm happy to pare it down further if there are too many extraneous objects)
Basically, open ds-slider-o-help.pd (which contains 10 copies of the GOP ds-slider-o.pd abstraction) and click the [CLICK TO CRASH( message which is connected to a [send] object with no destination.
Assigning a destination prevents the crash.
This would certainly make sense for my issues, as I use a ton of [s ] objects without arguments and it's likely that somewhere, one of them isn't being set properly.
I attached one of the crashlogs as well, which starts at "0 pd 0x00039cbe pd_typedmess + 142 (m_class.c:696)", but note that I also saw the "0 ??? ..." style crash as well that I'm assuming is indicative of corrupted memory?
I've tested this in Pd-extended 0.40 and in the latest Pd 0.42-3.
Best Luke