I have composed a M4L instrument patch only for isolating a reproduceable crash. It consists of a poly~ which receives midi from ableton live. The poly~ hosts only one instance of a very simple patch that does output a pure sine wave for dummy processing. The midi from ableton triggers a message ("TestCall TestSymbol") to a simple external, which does in fact nothing.
The problem is, that this TestCall-message sometimes forces the external to crash because of a corrupted t_symbol function parameter. Either the parameter is a NULL pointer or the t_symbol->t_name is a NULL pointer or it's a an illegal pointer even if it's not NULL.
This crash only occurs when the ableton live multiprocessor feature is enabled. And it's necessary to open more the one instance of the M4L instrument. I usually test with a number of at least four instances.
Please, has anyone an idea why this happens ? Is there anything obviously wrong with me ?
The zip file contains a frozen M4L device including the external and a ableton live set for testing. Also the c source code of the external is included.
Thank you for your attention. :-)
Poly~ patch ("ExternalTestInsidePoly.maxpat"):
And the c source extract of the mentioned external. This function is called by the message "TestCall TestSymbol":
ad 1) Yes, it is specific to M4L since the crash does not occur when multiprocessor support of Ableton Live is disabled.
ad 2) Yes, but the short answer was, that they don't give support for 3rd-party externals and I should paste my findings into the developer forum.