Unity Editor: SIGILL on patch load

[re-sounding]

Unpredictable error. Haven't figured out what is causing it yet.

[patricksebastien]

This happen in Unity Editor Windows too, 1/3 of the time.

[thefuntastic]

Okay, I've found the source of the error. Or at least one of the sources.

Reproduce case: In the scene: 01_LibPd_Basic.unity Happens once the editor is put into play-mode for the second time.

I managed to track this down to a dodgy pointer being set in libpdcsharp. I'm not really sure how to fix this as it has to do with the internals of the libpdcsharp wrapper. Should probably try get the fix applied upstream.

This doesn't happen in the scene 02_LibPd_ADC.unity. Not sure why though. Created my own scene similar to 01 and the problem presented there as well.

The problem: On start up LibPDNativeMessaging.cs passes print hook callbacks to libpd, in the function SetupHooks(). By commenting out the set_printhook call (line 91) it hints at the error as it goes away, but then you lose print statements from lippd.

SetupHooks() is called by ReInit(). After all the callback hooks are set it then internally calls libpd_init(). libpid_init() then takes the value set during set_printhook (stored in the csharp wrapper var libpd_printhook) and assigns it to (sys_printhook var, in the libpd c core).

This is where the problem comes in. libpd_init() has a safe-guard so that it only gets initialised once and exits early if you try to initialise again. What this means is that when you return from playmode, all the managed code gets destroyed, and thus all the print callbacks. But when you start again, the c code is still in memory, and won't reinitialize. This means the sys_printhook pointer still references the value from the previous play session and throws the SIGILL fault.

Suggested Fix?? I don't really know enough about libpd to suggest the best fix strategy. Ideally there needs to be a safe destruction routine we can call which allows us to make sure the libpd exits safely and can be reinited on play mode enter. I managed to get print hooks working by manually setting the sys_printhook var in the set_printhook c# wrapper call. This feels like a terrible hack, and ignores the problems that might arise from all the other hooks not being valid.

Open for any comments before I try take it upstream?

[js-duke]

There is a branch on libpd named "set-hooks" (https://github.com/libpd/libpd/tree/set-hooks) maybe that could fix our problem.

[danomatika]

Yes, I updated libpd with explicit hook setting functions as there were problems with some compilers using multiple instances of the function pointers. From the sound of it, that should solve your problem.

I updated the Csharp wrapper but did not test it as I don't have a Windows machine.

[danomatika]

I fixed the Makefile so the branch should build now and it's updated to the latest pd-vanilla source of 0.45-4. I've been meaning to merge these things to master, but haven't gotten around to it.

Also, currently there is no way for libpd to "exit safely". You can only init it and set the hooks.

[ghost]

Hi - I just logged an issue which sounds similar, before reading this and realising they could be related (here: https://github.com/patricksebastien/libpd4unity/issues/7 )

danomatika - how can I test?

[danomatika]

You need to rebuild the libpd csharp lib from the current libpd master. That should have all of the changes. Try that new lib and see if the bug goes away ...

See this on who to build it: https://github.com/libpd/libpd/wiki/Building-the-C%23-Api

[thefuntastic]

Sorry, been meaning to get round to this but drowning in work. If there is no feedback by tomorrow I will verify and see if the issue is resolved or not.

[ghost]

Thanks for the info, however just wrestling with MinGW.

At the end of my make csharplib I'm getting the following:

...

pure-data/src/d_soundfile.c:17:21: fatal error: pthread.h: No such file or directory

include < pthread.h >

                 ^

compilation terminated. make: *\ [pure-data/src/d_soundfile.o] Error 1

D:\OffRoot\GitHub\libpd>cp libs/libpdcsharp.dll csharp/bin/Debug/ cp: target `csharp/bin/Debug/' is not a directory: No such file or directory

[ghost]

pthread.h indeed doesn't appear to be in ...\libpd\pure-data\src

[danomatika]

It's not supposed to be part of libpd, it's the header for the POSIX thread library ...

pthread.h should be part of the Windows pthread implementation libpdthread-win32 and included with MinGW. From this thread, it looks like MinGW only comes with the compiled library and not the headers. Looks like you need to install the dev version of the library:

mingw-get install mingw32-pthreads-w32-dev

Note: I don't know if this works. I only spent a couple of minutes googling ...

[ghost]

After installing that - it seemed to be working further than before then went nuts and erroring for a long time. It's hard to trace back to the initial start of the error on this run

[thefuntastic]

Okay, so I've had a little of time to test on OS X (the behaviour is on both OSX and windows). It seems the error is still there. Though I need to spend more time actually looking at the problem - not sure I upgraded libpd in c# wrapper classes which have been customised for unity. I'll report back once I've had a bit more time to investigate

@andrewfriend in my experience the current version of MinGW doesn't work. I had to use a legacy version, as detailed here: http://www.thefuntastic.com/2014/04/the-misadventures-of-unity-and-puredata-libpd/

Furthermore, if you want to test your other error is related to this and save yourself the hassle of compiling a new dll, you can simply try comment out this line in LibPDNativeMessaging.cs. You will lose print statements but it should avoid the error.

PrintHook = new LibPDPrintHook(RaisePrintEvent);
//set_printhook(PrintHook);

[ghost]

@thefuntastic

Well done! Yes commenting out set_printhook(PrintHook) allows the scene to run without crashing in Unity Windows. Bravo :)

Will test on Android asap.

I really would like the updated libpd, as is using the latest build of vanilla pd, and OpenSL on Android. The LibPD_Basic scene is exhibiting clicks and pops on my Android device, so hopefully the OpenSL integration will remedy this.

So it looks like Android testing, and attempting the legacy MinGW build is next on my list.

[re-sounding]

Apologies, I haven't had much of a chance to work on this further. My intention was to commit the Android and Xcode build sessions — I will try and get that done ASAP so it can be used to build a newer version of libpd

@andrewfriend There really is no direct connection to openSL here. libpd4unity does not interface directly with openSL or Core Audio (or whatever other audio interface). It works as an extension of Unity's audio engine (FMOD) so even the latest version of libpd won't change that. Kalimba works by directly interfacing with the Android audio APIs but is limited in other ways. The clicks and pops could likely be because of the hardware buffer size and sample rate or other interrupts in the Unity audio system.

[ghost]

@ntkeep Thanks very much for the info, and all your efforts so far. I'll check the buffer size etc in Unity. I'm sure that will solve the issue.

Looking forward to the new build!

[ghost]

So the good news is that it's not crashing on Android or Windows with the work around.

The other news is that the LibPd_Basic scene is not working properly on Android. As in: it loads up, but there's no notes being played in PD, and the receiving text (top left) showing the noted being played in PD is static. This same scene works fine in Unity Windows.

The other LibPd_ADC scene appears to be working, but haven't verified if the audio is just playing in Unity, or indeed being routed via PD.

[jonbro]

just wanted to pop in and give a "hey this is still going wrong". Seems to crash on both the basic scene and the ADC scene in the editor on osx