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

Sep 11, 2013 at 6:37am

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

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 at 7:35am

The freeobject is a C function. And that function isn’t called only for Max/MSP “box” objects but for “nobox” objects also. It (usually) occurs in the main thread but not necessarily when you are freeing an external.

I’m not sure it’s a valuable clue if you can not identify first the object that crashes Max/MSP and then edit the sources (or in case of third party provide a solid crash report to the developer).

Sep 11, 2013 at 7:55am

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 11, 2013 at 8:18am

If you want to find what’s happened reading the crash dump, you should trace the frames further in the stack. Usually 20 – 50 lines to found a clue about the object concerned. But i’m not sure that this kind of investigation outclasses everytime a trial-and-error process ;-)

Sep 20, 2013 at 3:05am

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?

Sep 20, 2013 at 4:07am

This “freeobject” is the name of the function that crashes your process (i.e Max/MSP).
That call could be done by almost every object in Max/MSP. That’s not terribly helpful.

Sep 20, 2013 at 6:05am
– Pasted Max Patch, click to expand. –


For instance, with the patcher above i get the following crash report.


Exception Codes: KERN_PROTECTION_FAILURE at 0×0000000000000000
Crashed Thread: 2

Thread 2 Crashed:
0 com.cycling74.MaxMSP 0×00014853 max_crash + 3
1 com.cycling74.MaxMSP 0x0001c83d typedmess_fun + 1283
2 com.cycling74.MaxMSP 0x0001cb79 typedmess + 83
3 com.cycling74.MaxMSP 0x0001d1f9 aeval + 899
4 com.cycling74.MaxMSP 0x000083e0 atombuf_eval + 152
5 com.cycling74.MaxAPI 0x00f9cd91 atombuf_eval + 60
6 com.cycling74.message 0x1895a0ab jmessage_atombuf_eval + 429
7 com.cycling74.message 0x1895a407 jmessage_bang + 129
8 com.cycling74.MaxMSP 0×00065799 outlet_bang + 737
9 com.cycling74.MaxMSP 0x000652a9 outlet_int + 755
10 com.cycling74.MaxAPI 0x00f90330 outlet_int + 38
11 com.cycling74.counter 0x18900fe2 counter_output + 241
12 com.cycling74.counter 0x18901be4 counter_bang + 77
13 com.cycling74.MaxMSP 0×00065799 outlet_bang + 737
14 com.cycling74.MaxAPI 0x00f902e9 outlet_bang + 31
15 com.cycling74.metro 0x18907b37 metro_out + 77
16 com.cycling74.metro 0x18907b63 metro_tick + 38
17 com.cycling74.MaxMSP 0x001f60a6 time_qfn(_time*, long) + 32
18 com.cycling74.MaxMSP 0x001f6259 time_tick + 35
19 com.cycling74.MaxMSP 0x0002ac91 sched_takepoll + 483
20 com.cycling74.MaxMSP 0x0002ad46 sched_poll + 50
21 com.cycling74.MaxMSP 0×00067616 systimer_pollaction + 50
22 com.cycling74.MaxMSP 0x00067a78 mactimer_isr() + 108
23 …ple.CoreServices.CarbonCore 0x945d4c4d TimerThread + 291
24 libSystem.B.dylib 0x91a64259 _pthread_start + 345
25 libSystem.B.dylib 0x91a640de thread_start + 34


In which you can easily infer the problem by rolling back the frames.


25 thread_start

16 metro_tick
15 metro_out
14 outlet_bang
13 outlet_bang
12 counter_bang
11 counter_output
10 outlet_int
9 outlet_int
8 outlet_bang
7 jmessage_bang

0 max_crash


Of course more you are used with the SDK (and JUCE and system calls…) more it is easy to guess what a function refers to.

Nov 22, 2013 at 5:32am

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.

Nov 22, 2013 at 8:21am

by assuming a “freeobject+52″ could actually be one of an “obj-52″ in a patch


- AFAIK the +52 is an offset in the assembly code. Absolutely NOTHING related with the name of an object.
- “freeobject” is a C function used by almost EVERYTHING in Max.

The only clue you can get with a crash report is to rolling back the frames and try to recognize a BOX object in the flow.

My 2 cents.

Jan 16, 2014 at 9:13am

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?


You must be logged in to reply to this topic.