In my experience, that 0.8.21 Iannix build runs perfectly on OSX 10.6.7, so there might be something anomalous in your installation.

Did Iannix crash on its very first invocation following your upgrade from 10.5, or were you able to open a score or do some edits before it began crashing on launch? I’m wondering if it is attempting to load a file that is corrupted (sometimes apps in early beta don’t have all the input validation in place, and bad data might cause an out-of-bounds access). To eliminate the possibility of a bad startup file, you might try temporarily relocating your data out of the « Project » subfolder so Iannix will not find anything to open upon launching.

When you upgraded to 10.6, did you do a clean install or an upgrade install? I don’t have any particular issue in mind, but if you did an upgrade, I wonder if some kind of corruption of your app occurred. If you haven’t already done so, it might be worth your time to reinstall Iannix.

Yes, from your stack trace, it does look like it was in a QT call before vectoring through address zero, but 90% of the time an app built on QT will be inside a library call. The invalid access comes out of the Unicode conversion call, and that might be while parsing the name of the default score file. It is unlikely to be a « QT problem », per sé, because all of the QT runtime support required by Iannix is inside of iannix.app — your QT dev tool installation should have no bearing on this.

@mrgosh wrote:

I’m trying to run from an install of the latest release, yeah. Not building from source.

Cheers,
–Bob

No reason to feel silly. I looked at the source code to get one or two of those :–)

Cheers,
–Bob

@ongo wrote:

Nice one AvantGuy

feel slightly silly now seeing how simple it is really !!!

…related? I think you might be teasing us with an understatement :–) It sure does look related. A comparison of your crash dump with that QT bug report crash dump is more like twins than kissing cousins. Both crashes occur very early in the app startup sequence. I mean, when you can see the entry to main() less than a dozen stack frames before the crash, you *know* the app is still cranking its engine when it dies. Plus, they both croak from that Unicode call (well, you got one more stack frame before death than did this other event, but that might just be a difference in QT versions and some kind of function re-factoring QT might have done).

It’s looking to me like this issue results from a combination of a particular hardware configuration and OSX 10.6, based on the problem-free experience I’ve had with Snow Leopard. Just what is your hardware? Mine is a first generation Macbook with RAM maxed out.

Have you applied all CMOS patches to your hardware? You might want to ensure you’re totally up to date with system patches.

–Bob.

Understatement be my curse!

I’m on a 2.8Ghz MBPro5,1 4G ram (max).

Found some troublesome fonts and killed them but that didn’t make any difference (it was a longshot anyway, I know). My SMC and bootrom are both up-to-date. The only thing I’m not up to date on is OS because digi hasn’t qualified 10.6.8 yet (of course).

This is one hell of a mystery – on both the Iannix and Qt-in-general fronts.

EDIT: I wonder if its possible that this is a 32-bit v 64-bit problem. That might set off all these flags… Bob, is your machine Core2Duo or no? Mine has 1x 64-bit core.

@Guillaume wrote:

Do you download the last version of IanniX? Because in the last version, we included a transport message …

I must have looked at that ten times; didn’t even realize it was there 😳 !

Hi Guillaume,

In another thread you mentioned:
@Guillaume wrote:

… in the last version, we included a transport message that sends

osc://127.0.0.1:57120/transport status nb_triggers nb_cursors nb_curves

on Play and Fastrewind.

This is so great. For those of us using SC, it means we can have the OSCresponder listening on play figure out how many synths to activate, rather than coding the number in the SC patch as the ones you provided do. As I mentioned in the other thread, we could tumble to these features quicker if they were documented.

By the way, I think there is a bug in your « gendy » patch. the responder for cursors assigns an ordinate (X-axis) value to a variable that seems to think it’s an abscissa (« Y »). If you use that to assign frequency, it won’t do the expected. Perhaps you intended to supply us a friendly puzzle?

thanks for your support!
–Dick