Crash in class_attr_method

    adamflorin
    Aug 21 2013 | 12:57 am
    I've been getting crashes in class_attr_method() in an M4L project for a while now. One example Mac crash report:
    https://gist.github.com/adamflorin/3fb2e54226605ac32d00
    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:
    1. Just as the message is entering a [patcher]
    2. 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!
    • Trond Lossius
      Aug 21 2013 | 1:56 pm
      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:
      https://github.com/jamoma/JamomaModular/commit/73648b96ff69eca36a0bbe20feb42d034427df7d
      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
    • adamflorin
      Aug 21 2013 | 5:06 pm
      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.
    • Emmanuel Jourdan
      Aug 21 2013 | 10:49 pm
      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.