could the same 'free objects' be causing crash each time?

    Sep 11 2013 | 1:37 pm
    hey there and hello from newb
    i get crashes quite consistently with the crahed thread reporting this at the last line….
    Thread 0 Crashed:: Dispatch queue: 0 com.cycling74.Max 0x000369a8 freeobject + 52 1 com.cycling74.Max 0x00036b4f freeobject + 475
    its the same two free objects and hex name so i’m thinking that these are the consistent issue in these crashes, no matter whaich thread crashes – the same two are at the last line….
    what are free objects? ( i think from reading up a bit – that theyre objects no longer needed and ‘disposed of’ but not too sure…..and how might i track down an object is becoming free and crashing max?

    • Sep 11 2013 | 2:55 pm
      thanks, BTW that links to my other post in 'dev' because it was suggested i try there too.
      but re: my problem, its quite often, nearly always thread 6 crashing.
      i wonder how to find out what operations are within the threads, so i can narrow down my search
    • Sep 20 2013 | 10:05 am
      yeah i would like to try but dont really know where to begin, as first i would need to know the 'link' between the free object entry in the list and the actual objects they were related to, at the moment there seems to be the same two freeobjects at the last line, in fact the similarity is very much the same all the way up the crash log, in many cases its identical... but
      Thread 6 Crashed: 0 com.cycling74.Max 0x000369a8 freeobject + 52 1 com.cycling74.Max 0x00036b4f freeobject + 475
      always these two.
      how could i find out what exactly were the 0x000369a8 freeobject +52 for example?
    • Nov 22 2013 | 1:32 pm
      thanks for your guidance there, i have read the steps towards the last 'crashing' lines in the schedule but i guess with many patches running i have to be able isolate which of these might be even close to the reason for the crash.
      i'm now thinking that by assuming a "freeobject+52" could actually be one of an "obj-52" in a patch for example by looking for preset files' text - searching for "obj-52", then assuming that any patchers using such a numbered object in them could be one of the patches causing the crash, starting from here gives me reason to think i'm narrowing the search down from trial/error elimination processes.
    • Jan 16 2014 | 5:13 pm
      I read this call stack as saying a metro sends bangs to a counter object. This counter object is (eventually) connected to a message box that sends the message:
      ; max crash
      Which is a message that intentionally crashes Max. So maybe things are working as intended?