I’m attempting to incorporate the NYU corelink project into a custom operator and having some trouble with it. I have everything set up correctly in xcode so that the builds are succeeding and I’m seeing the correct variables when I step through the code via the xcode debugger, but no matter what I try I run into some kind of bad access deep in the asio files and me and the corelink developers are scratching our heads. Does anyone know if TouchDesigner expressly won’t work with Asio?
Hi - it’s difficult to know from this description if the problem is caused by TouchDesigner or not. It’s possible some libraries TouchDesigner uses are also used by Corelink and TouchDesigner’s version of them is being loaded instead of the version linked against by Corelink - perhaps.
You should see a crash report in the Console app under Crash Reports - if you could attach or paste one of those here it might give some clues. If you don’t see any, run TouchDesigner normally (without Xcode attached) and cause your plugin to crash, then wait a few minutes for the report to be generated.
Ok this is from a few days ago but the BAD_ACCESS seems familiar. It looks like it doesn’t permit me to add .ips files to the forum so I’ll turn the error log into a snippet. I’m actually having a hard time getting it to crash with some of my more recent changes. The behavior instead is that the program is staying open and unresponsive. If I can get it to fully crash without forceQuit I’ll attach that error log too.
Ok, here’s the most recent version of the crash. I know it’s a little weird that it has to be this way, but I feel like I’m learning tons about the cplusplus operators in this endeavor.
Thanks for these. I don’t see anything which makes me think TouchDesigner is involved.
I do see you’re using a Homebrew-installed version of libwebsockets, so I’d suggest you confirm the installed version is compatible with the version of Corelink you’re using. That is the only third-party library implicated in the crash, as, as you say, Corelink and its dependencies seem to be entirely header-based.
Perhaps elsewhere you are trashing memory which is resulting in a bad pointer value being passed, or freeing something which is still in use. If you run the plugin in Xcode you can break in the debugger when it crashes and you may find unexpected values there which give you somewhere to start hunting backwards from. Xcode will also show you any output printed to the console which may include some clues.
Thanks for taking a look at those super dense files. It’s great to hear that there’s nothing you are immediately spotting that suggests that I can’t use Asio with a custom operator, because I think that would mean having to go a very different direction.
Starting up with xcode connected as a debugger has been a useful practice, and I think perhaps there’s something going on with losing functions or variables that go out of scope in between when they are bound in callbacks and when Asio tries to use them.
I might look into finding a simple Asio application that I can run with first just to clear up whether it’s the primary contributor to the problem or if it’s something on the corelink side.
Ok, just to get some more information out there, I’ve gotten help from the corelink devs and we have a semi working version of the system that doesn’t crash anymore. I think this again suggests that there isn’t any reason asio wouldn’t work in conjunction with a touch designer cplusplus operator.
I’ll post one more time to close this when I can not only send messages from within the operator but also receive them.