pd~ fails to launch subprocess in some cases

Which then apparently makes the object run wild (hogging cpu and main memory) listening on a connection whose other end is dead on arrival already.

The main culprit seems to be the execv call in the not-WIN32 part of pd_tilde_donew (at pd~.c:399), with its hard-coded path to the pd-l2ork binary:

    execv("/usr/lib/pd-l2ork/bin/pd-l2ork", execargv);

It goes without saying that this won't work if the binary is installed elsewhere, as in the JGU packages or on the Mac. Is there a reason that we don't use the pdexecbuf variable there, as we do in the _WIN32 part?

Also, the code leading up to that (starting at line 229) tries quite a few things to locate the binary, but looks for just pd (rather than pd-l2ork) in most cases, is this intentional?

In any case, we must also look into why the object then goes ballistic hogging cpu and main memory (the latter is really deadly if it goes unnoticed at first, because it may well render the system unusable when it starts swapping, leaving the user unable to even kill the runaway process).