I've been working on a project using pd and the raspberry pi that includes writing Pd-extended externals on my mac.

When I came to debug the externals that were working flawlessly on my mac, I was getting segfaults on the pi. I tried to reduce the two externals that seemed to cause trouble together to their simplest states, which can be seen here.

As you can see, the code for the two objects are almost identical. However, when creating a patch, whichever external gets put into the patch first gets the message sent to the second one!

For instance, i might open pd-extended and make a blank patch, add the 'cmidi' object and attach a float to it, then add the 'elswating' object and attach a float to it. Now, if I click the float attached to elswating, the pd window will post "cmidi bang!", when it should post "elswating bang!".

this phenomena occurs in reverse if the elswating object were created first, with floats to either object posting "elswating bang!".

I compiled the code on the raspbpi using the "Pd library template version 1.0.14" that can be found here. The compilation spits out a "*.l_arm" file that I rename to "*.pd_linux", otherwise pd-extended fails to load them altogether.

I should also mention that I place the binaries in the '~/pd-externals' folder, and have also tried putting them in '/usr/local/lib/pd-externals' to no success.

Thanks in advance for any help!

I've experienced that phenomenon more than once: objects which influence one another while they shouldn't. This points to illegal memory access. Normally, a process segfaults on illegal memory access, but with Pd externals that is not always the case because Pd reserves some memory, and your external may happen to load in that memory and not crash Pd even while accessing memory locations that it did not reserve itself. Therefore, such an external may make Pd crash in one situtation while it doesn't crash in another situation. By way of test, create many instances of the same external (10 or 100 or so), and if there's illegal access it will probably crash Pd.

In your case you have reduced functionality to a minimum and still there's something wrong with memory access. The classes are so simple that it's hard to imagine where it could go wrong. Only thing I noticed is, you cast class pointers to void when returning them in the 'new' function. Instead of 'return (void *)x;' you could try 'return x;'. I guess the void return type is only declared because when Pd calls the function it doesn't know the type yet.

Katja

Thanks for the reply katjav!

I noticed earlier that the float response method had the same name in both objects, and it appears that this is what was tripping Pd up. I changed the name from "out_bang" to "snout_bang" in one of the objects, and voila, it works. Very strange.

Ah, that explains the issue. Both functions were exported. It is in general a good idea to not export functions if they are meant to be local. So, declare like:

static void out_bang()

rather than:

void out_bang()

Only the setup function needs to be exported. Your issue is an example of symbol collision, see:

https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html

I never knew that symbol collision can happen so easily in Pd. Let's keep this in mind. Thanks for posting.

Katja