Crash in class_attr_method
I've been getting crashes in class_attr_method() in an M4L project for a while now. One example Mac crash report:
The backtrace always begins with:
Thread 17 Crashed:: com.apple.audio.IOThread.client
0 com.cycling74.MaxPlugLib 0x1a8cf6c7 class_attr_method + 56
1 com.cycling74.MaxPlugLib 0x1a8cf078 object_attr_method + 115
2 com.cycling74.MaxPlugLib 0x1a8da237 typedmess_lookup + 179
...
I can follow the backtrace before that through my patch, starting at the [timepoint] object (line 30 in the backtrace) through [trigger]s, [route]s, etc. Based on the layout of my patch, where this crash occurs is either:
Just as the message is entering a
[patcher]OR, just as the message is exiting the current patcher (which is an abstraction, embedded in another abstraction) via an
[outlet]
But I don't know what typedmess_lookup() or object_attr_method() are doing, either.
Does anyone have any insight here? Thanks!
Hi,
As far as I know, typedmess_lookup() is a method used by Max in order to determine if a message arriving at an object is a bang, float, int or something else, so that it can pass it on to the correct method of the object.
I would suspect that you might have an invalid pointer at this point (e.g. a pointer to NULL), and this cause it to crash. If so, it might be that the real root of the issue is located elsewhere, but that the invalid message is being passed around for a while before it eventually explodes.
Apart from that, if this crash happens in an external of yours, another thing that you might try, is a similar fix to one we did some years ago when we had a related crash. You can find the commit log for that fix here:
As you can see we changed the calls relating to the dumpout outlet. I don't remember the details any more, but I hope that it still might be of help to you.
Cheers,
Trond
Huh! That's a compelling theory—that the message itself was corrupted further upstream. My specific patch doesn't use any home-compiled externals, but I appreciate the commit log, too.
Thanks for your help, Trond! I'll keep chipping away at it.
It's likely to be a threading problem. Without seeing the device it's hard to tell, but I'd suggest you defer the bang coming out of the timepoint object to see if that solves the issue.