Forums > Dev

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

September 11, 2013 | 6:37 am

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: com.apple.main-thread
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?


September 11, 2013 | 7:55 am

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


September 20, 2013 | 3: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?


November 22, 2013 | 5:32 am

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.


January 16, 2014 | 9:13 am

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?


Viewing 5 posts - 1 through 5 (of 5 total)