rtcmix~ 1.6 crash on Max 4.6.3
It crashes on both Intel and PPC but rtcmix~ 1.7 works fine on Max5 on the same machines.
PPC is MacOS 10.4.11 and Intel macbook pro is 10.5.6
Is it rtcmix~ 1.6 or me?
OK — I know what’s going on. In the crashlog:
> Thread 0 Crashed:
> 0 FTMlib 0×17214412 yyparse + 2045 (parser.y:250)
> 1 com.bgg.rtcmix~ 0x1755f229 rtcmix_dotext + 692
it seems there is a conflict between rtcmix~ and the new FTMlib from IRCAM. I bet you have FTMlib installed on your 4.x machines and not on your newer one (or if not, then the external functions are better ‘protected’ under 5).
I’ve had one other report of a crash like this, I’ll see if we can figure out a fix.
Unfortunately I need both FTM and rtcmix~ in my current project.
I also need Max 4.6.3 for the time being.
Do you know where I can find a previous rtcmix~ version(1.5?) it was working well on my system and I could keep on working in the present time.
Unfortunately it’s still crashing with 1.56.
So it must be my version of FTM(2.3.2).
I check with the FTM team and let you know.
It definitely worked few weeks ago with FTM. Strange enough.
Hi Brad, Hi Jean-Michel,
I have exactly the same problem.
rtcmix 1.7, ftm 2.5beta, max 5.0.6, mac os x 10.5.6 (intel).
Thread 0 Crashed: 0 FTMlib 0x18c4b0bc yyparse + 2252 1 com.cycling74.rtcmix~ 0x19c787e3 rtcmix_dogoscript + 646 (rtcmix~.c:1157) 2 com.cycling74.MaxMSP 0x0002d400 defer_exec(_defer*) + 60 3 com.cycling74.MaxMSP 0x00025375 sched_dequeue + 119 4 com.cycling74.MaxMSP 0x0000f425 max_tick + 77
I suppose both libs have a function named yyparse
(I see in the RTcmix conf.tab.cpp that there are some preprocessor stuff with function pointers defining yyparse).
Maybe It would enough to rename that specific function.
I could give it a try but I’m assume you (brad) will be more comfortable with this.
I think I know what’s happening, but I haven’t had time to do some thorough testing, etc. yet. I discovered when moving to OSX 10.5 that the behavior of Apple’s CFBundleLoadExecutable() seems to have changed in that the symbol space of the loaded dylib was ‘exposed’ to the rest of the executing app. It didn’t used to be this way, and many attempts to coerce the Core Foundation dylib-loading functions to maintain a private symbol table didn’t work. This was important because I needed the capability to instantiate multiple rtcmix~ objects without each one interfering with the others. I wound up using NSLinkModule() with the appropriate flags set and it worked.
I suspect that the IRCAM FTMlib is not doing this, or the Cycling .mxo loader is not doing this, and the FTMlib yyparse() function is being hit before the local rtcmix~ yyparse(). Unfortunately yyparse() is very common function for developers who have used yacc or lex (bison or flex or whatever it’s called now), and there are also many subsidiary functions that will probably also cause problems (plus these functions are all generated automatically by the compiler-builder).
When I get a chance to investigate more thoroughly I hope to post a more coherent set of questions on the dev-list. Hopefully there is an easy and elegant solution of which I am unaware.
This will also affect the chuck~ object, too because the ChucK developers also used yacc/lex for their parser.
I’m not sure I understand. Do you mean that several rtcmix~ can interfere between each other ? that chuck~ can interfere with rtcmix~ too ? or is it just happening with FTM ?
Here, when removing the _FTM_.pat from C74/max-startup everything is/seems fine (even with multiple rtcmix~ examples).
If it is just related to FTM, and before you’ll have time to fix it, you should note it on rtcmix~’s website.
It took me half an hour to understand why it was always crashing and I almost gave up til I saw the magical FTMlib word in the crashreport.
But I’m afraid lots of people won’t be as patient or won’t read (or won’t be able to interpret) the crash report, so that they’ll miss this great tool, would be a pity.
I must say that the incompatibility with FTM is the same on Mac Intel, PPC, on Mac OS 10.4.11, 10.5.6 and on Max/MSP 4.6.3 and Max5.
When unistalling FTM it works well except for one thing: standalones built with rtcmix~ inside will crash. Tested on all the configurations above.
Here is the crashlog when launching the standalone, the app building script inside Max doesn’t report any error.
|Date/Time: 2009-03-11 09:32:57.194 +0100
OS Version: 10.4.11 (Build 8S165)
Report Version: 4
Version: 5.0.4 (35808) (5.0.4)
Exception: EXC_BAD_ACCESS (0×0001)
Thread 0 Crashed:
Thread 0 crashed with PPC Thread State 64:
Binary Images Description:
Model: PowerMac7,3, BootROM 5.1.8f7, 2 processors, PowerPC G5 (2.2), 1.8 GHz, 4 GB
Hi Leo –
> I’m not sure I understand. Do you mean that several rtcmix~ can
> interfere between each other ? that chuck~ can interfere with
> rtcmix~ too ? or is it just happening with FTM ?
No, rtcmix~ and chuck~ load in a fashion that prevents these conflicts. I did discover that chuck~ + FTMlib will also crash. I just posted a note to the dev-list to see if anyone has ideas about a solution to the namespace conflict.
> If it is just related to FTM, and before you’ll have time to
> fix it, you should note it on rtcmix~’s website.
That’s a good idea. I’ll do it later this evening.
> It took me half an hour to understand why it was always
> crashing and I almost gave up til I saw the magical FTMlib
> word in the crashreport.
Oh I am sorry! I know how you feel!
Thanks for being patient…
The standalone crash is a different issue, and I know exactly how to fix it. I posted this on the RTcmix-discuss list, but like a big idiot I forgot to put it on the web page!
[rtcmix~] (and [chuck~], and apparently IRCAM’s FTM objects) rely on external libraries that are dynamically-loaded into Max/MSP when the objects run. When Max builds a standalone, it copies the rtcmix~.mxo object but does NOT copy the dynamic library. You need to do this ‘by hand’ into your standalone application bundle.
What you should do is copy the RTcmix/ folder from the MaxMSP/externals directory into your MyApp.app/Contents/support/ sub-folder, and then *remove* the rtcmix~.mxo object that is in the top-level of the RTcmix/ folder. This should leave only the rtcmix-dylibs/ folder. You need to remove the rtcmix~.mxo because it has already been included in the standalone build process. Retaining the rtcmix-dylibs/ folder in that directory will allow the rtcmix~ object to find the resources it needs.
For a recent example, you can download the "BookOfDreams" application I built:
and take a look at the BookOfDreams.app/Contents/support/ folder to see the RTcmix/ folder inside.