Insta/hard crash

Was just working with my performance patch and it insta-crashed on me. I wasn’t “doing anything” when it happened, just having the patch idly running.

I don’t know if it’s FluCoMa-related as I’m not great at reading crash reports, but the offending thread appears to be:

Thread 25 Crashed:
0 libsystem_malloc.dylib 0x00007fff62a923eb nanov2_allocate_from_block + 615
1 libsystem_malloc.dylib 0x00007fff62a91a61 nanov2_allocate + 130
2 libsystem_malloc.dylib 0x00007fff62a9198e nanov2_malloc + 56
3 org.chromium.ContentShell.framework 0x000000011818320d 0x115952000 + 42144269
4 org.chromium.ContentShell.framework 0x000000011818320d 0x115952000 + 42144269
5 libsystem_malloc.dylib 0x00007fff62a84dfd malloc_zone_malloc + 103
6 libsystem_malloc.dylib 0x00007fff62a84d79 malloc + 24
7 com.cycling74.Max 0x0000000108b1f443 sysmem_newptr_imp + 24
8 com.cycling74.Max 0x0000000108b8e229 linklist_append_nolock + 38
9 com.cycling74.Max 0x0000000108b8cfa7 linklist_append + 34
10 com.cycling74.Max 0x0000000108c4002e sysqelem_set + 73
11 multislider 0x00000001157e5736 multislider_float + 122
12 com.cycling74.Max 0x0000000108b99b5b outlet_float + 673
13 com.cycling74.Max 0x0000000108b99c30 outlet_float + 886
14 com.cycling74.Max 0x0000000108b99b5b outlet_float + 673
15 com.cycling74.Max 0x0000000108b99b5b outlet_float + 673
16 com.cycling74.Max 0x0000000108b99c30 outlet_float + 886
17 com.cycling74.Max 0x0000000108b996f2 outlet_int + 891
18 com.cycling74.Max 0x0000000108b996f2 outlet_int + 891
19 com.cycling74.Max 0x0000000108b56e06 stdin_input + 142
20 com.cycling74.Max 0x0000000108b084c8 typedmess_fun + 216
21 com.cycling74.Max 0x0000000108b9a7b9 outlet_anything + 627
22 com.cycling74.Max 0x0000000108b8e9af linklist_funall_imp + 111
23 com.cycling74.Max 0x0000000108b736cf through_scheduler_sendit_extended + 148
24 com.cycling74.Max 0x0000000108b73635 through_scheduler_sendit + 20
25 com.cycling74.Max 0x0000000108b56d38 stdin_sendinput + 284
26 com.cycling74.Max 0x0000000108b1ab5a sched_midipacket_scheduler_impl + 269
27 com.cycling74.Max 0x0000000108b1b1ae sched_takepoll + 420
28 com.cycling74.Max 0x0000000108b9fb9c mactimer_isr + 192
29 com.cycling74.Max 0x0000000108b9d8f8 systhread_threadproc + 64
30 libsystem_pthread.dylib 0x00007fff62ace2eb _pthread_body + 126
31 libsystem_pthread.dylib 0x00007fff62ad1249 _pthread_start + 66
32 libsystem_pthread.dylib 0x00007fff62acd40d thread_start + 13

I have no idea what those first few things in there are…

Here is the complete report: (36.6 KB)

If it’s not FluCoMa-related, I’d appreciate any input/thoughts on wtf is going on here, as it’s not a comforting feeling that the patch can just die like that…

Don’t know if this is relevant/related, but this is what Console says was happening just before the crash:

I’m pretty sure it is your nanov2 object making bad memory allocation. @a.harker will read this as poetry, so I’ll let him help here but nothing looks like a FluCoMa bug in this…

I don’t know what nanov2 would be.

Yeah, input would be appreciated.

Our stuff isn’t mentioned, so it’s not directly us. Not impossible that a buffer overrun has corrupted some other part of Max’s memory, and caused it to die here, but there’s nothing to point to us at the moment. If you have a way of reproducing, then we can narrow it down.

The crash itself is happening when multislider attempts to allocate memory, which does seem weird. I’ve no idea about the nanov2 stuff.

ok here goes the amateur: I presume you have all the code/read me of all the externals you use… I’d check for the word ‘nanov’ in there - it is peculiar enough to pop out :wink:

Something is messing about with memory allocation… have you tried it in Max7?

are you using this for your performance?

So it looks like have 3 multisliders in my patch. 2 are leftover from prototyping/testing and have now been removed. There is one that is just a UI mirror of my crossfader thing, which I’ve now chucked a deferlow in front of (another point for my t-shirt idea!).

The patch did crash while I was messing around with the crossfader, so that could possibly be it.

Is the crash report demonstrative of a multislider bug which I should report to c74 (like, should multislider be allocating memory at all?), or is it more of an odd/fluke-ish thing?

I was hoping to keep it a secret…

(there’s nothing called nano, or nanov2 in my patch)

I wouldn’t start distrusting multislider just yet. What’s in the crossfader?

That nanov stuff is, I think, to do with the OS; the only references I can find to those function names all concern Mojave (10.14), so maybe it’s some badness there that we haven’t encountered (still on 10.12).


Sorry, missed the last part. If it’s only happened the once, then odd/flukish. If you find a way of making it happen reliably, then this will probably give a good pointer as to whether it’s a C74 thing, or due to some other object corrupting memory.

multislider will probably allocate when the size of its input list changes, especially in history mode, as it has to maintain its own list-of-lists to give you that view.

Please, make two :wink:

The crossfader is a DIY Teensy thing which is just sending MIDI into Max (via two CCs for 14-bit resolution):

The multislider itself is just there for looks, basically something like this:

I am on Mojave, which points to that.

Is the fact that the nanov2 thing is the last thing in the crash report indicative of it being what crashed Max, or is it the multislider thing that did it, with a couple of bits happening after that before it all blew up?

Just to stress test things, I’ve had the patch running for the last hour on my laptop and there’s been no issues. (also not using the crossfader)

If it happens again, I’ll try removing the multislider altogether since it’s not really doing anything in the patch other than looking pretty.

I mean, look at these faux-3d thing(!):

Not really; it marks the point that a Bad Thing happened, but not what, or where the rot set in. At the top of your crash report will also be an exception code, which would give a little more (not much) information about what manner of Bad Thing happened. Weird crashes like this can be down to all kinds of things, like accessing memory that’s already been freed, or something else writing to the wrong place, or some precondition not being met, or an actual allocation failure (though that is very rare if you haven’t run out of memory).

I don’t see anything alarming in the patch you posted. It is very bling :hearts:


nano whatever in a call to malloc almost certainly means you are allocating what the OS considers to be a very small amount of memory.

The crash is EXC_BAD_INSTRUCTION, which normally (if I recall correctly) means an instruction that doesn’t exist on the given processor. The thread is a scheduler thread and as mentioned above the multislider initiates the allocation (in this case in the high priority thread). That doesn’t seem so unusual, but the instruction error is unusual - it’s possible it could also happen in a memory misalignment situation, but I can’t be sure if that is a correct statement or not.

In the main thread JUCE is trying to draw text to the screen, and there is also a call to nanov2_allocate_from_block, which might point to some rather bad threading issues (possibly, although I’m hesitant to ever diagnose this - at OS level).

This might be an OS error, or it is some very weird stack/heap corruption, but there’s nothing anyone can make use of here from the flucoma end and there’s no clear indication that this is flucoma related. There are no fluid objects I can see in any of the stack traces, so the only way this could be related to flucoma is that memory corruption has occurred, but at this point in time in the crash that’s no longer traceable.


Hmm, this has dreadfully returned.

With a much more c74-facing crashed thread.

I’ve not actually seen one with so much of the same/similar message in a row. It happened the moment I enabled a M4L device inside Max.

Don’t think it’s FluCoMa-related, but any thoughts/inside would be much appreciated, particularly being a few days out from the gig…

(I’ve disabled the multislider/UI feedback altogether and will keep practicing/stress testing with my fingers crossed)

Thread 25 Crashed:
0 libsystem_kernel.dylib 0x00007fff6d16e2c6 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff6d229bf1 pthread_kill + 284
2 libsystem_c.dylib 0x00007fff6d0d8745 __abort + 144
3 libsystem_c.dylib 0x00007fff6d0d86b5 abort + 142
4 libsystem_malloc.dylib 0x00007fff6d1e716b malloc_vreport + 545
5 libsystem_malloc.dylib 0x00007fff6d1fff01 malloc_zone_error + 183
6 libsystem_malloc.dylib 0x00007fff6d1eba53 nanov2_realloc + 334
7 org.chromium.ContentShell.framework 0x00000001137d7364 0x110fa6000 + 42144612
8 org.chromium.ContentShell.framework 0x00000001137d7364 0x110fa6000 + 42144612
9 libsystem_malloc.dylib 0x00007fff6d1e3b42 malloc_zone_realloc + 111
10 libsystem_malloc.dylib 0x00007fff6d1e3a76 realloc + 253
11 com.cycling74.Max 0x000000010c1a0055 void juce::HeapBlock<juce::Rectangle, false>::realloc(unsigned long, unsigned long) + 29
12 com.cycling74.Max 0x000000010c1a001d juce::ArrayBase<juce::Rectangle, juce::DummyCriticalSection>::setAllocatedSize(int) + 37
13 com.cycling74.Max 0x000000010c201238 juce::ArrayBase<juce::Rectangle, juce::DummyCriticalSection>::createInsertSpace(int, int) + 56
14 com.cycling74.Max 0x000000010c73130a juce::RectangleList::subtract(juce::Rectangle) + 314
15 com.cycling74.Max 0x000000010c856697 juce::StandardCachedComponentImage::invalidate(juce::Rectangle const&) + 23
16 com.cycling74.Max 0x000000010c7a3441 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 81
17 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
18 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
19 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
20 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
21 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
22 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
23 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
24 com.cycling74.Max 0x000000010c7a34e8 juce::Component::internalRepaintUnchecked(juce::Rectangle, bool) + 248
25 com.cycling74.Max 0x000000010c073729 svgcolor_int(_svgcolor*, long) + 47
26 com.cycling74.Max 0x000000010c005592 typedmess_fun + 418
27 com.cycling74.Max 0x000000010c0ef85b object_method_typedfun + 133
28 max~ 0x000000011bac6bbd plugintoolbar_setbypass + 71
29 com.cycling74.Max 0x000000010c0f042c object_attr_setvalueof + 174
30 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
31 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
32 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
33 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
34 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
35 prepend 0x0000000122be3ab0 prepend_list + 234
36 prepend 0x0000000122be398e prepend_int + 48
37 com.cycling74.Max 0x000000010c0966f2 outlet_int + 891
38 toggle 0x000000011b5faf2e jtoggle_int + 25
39 com.cycling74.Max 0x000000010c096246 outlet_bang + 1068
40 com.cycling74.Max 0x000000010c0966f2 outlet_int + 891
41 toggle 0x000000011b5faf2e jtoggle_int + 25
42 com.cycling74.Max 0x000000010c096616 outlet_int + 671
43 com.cycling74.Max 0x000000010c067321 route_anything + 302
44 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
45 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
46 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
47 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
48 com.cycling74.Max 0x000000010c08b9af linklist_funall_imp + 111
49 com.cycling74.Max 0x000000010c0706cf through_scheduler_sendit_extended + 148
50 com.cycling74.Max 0x000000010c070a4d through_scheduler_anything + 20
51 com.cycling74.Max 0x000000010c0688fe send_anything + 40
52 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
53 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
54 prepend 0x0000000122be3ab0 prepend_list + 234
55 prepend 0x0000000122be398e prepend_int + 48
56 com.cycling74.Max 0x000000010c0966f2 outlet_int + 891
57 com.cycling74.Max 0x000000010c096616 outlet_int + 671
58 com.cycling74.Max 0x000000010c067031 route_list + 337
59 com.cycling74.Max 0x000000010c097036 outlet_list + 574
60 com.cycling74.Max 0x000000010c0966f2 outlet_int + 891
61 com.cycling74.Max 0x000000010c053e06 stdin_input + 142
62 com.cycling74.Max 0x000000010c0054c8 typedmess_fun + 216
63 com.cycling74.Max 0x000000010c0977b9 outlet_anything + 627
64 com.cycling74.Max 0x000000010c08b9af linklist_funall_imp + 111
65 com.cycling74.Max 0x000000010c0706cf through_scheduler_sendit_extended + 148
66 com.cycling74.Max 0x000000010c070635 through_scheduler_sendit + 20
67 com.cycling74.Max 0x000000010c053d38 stdin_sendinput + 284
68 com.cycling74.Max 0x000000010c017b5a sched_midipacket_scheduler_impl + 269
69 com.cycling74.Max 0x000000010c0181ae sched_takepoll + 420
70 com.cycling74.Max 0x000000010c09cb9c mactimer_isr + 192
71 com.cycling74.Max 0x000000010c09a8f8 systhread_threadproc + 64
72 libsystem_pthread.dylib 0x00007fff6d2272eb _pthread_body + 126
73 libsystem_pthread.dylib 0x00007fff6d22a249 _pthread_start + 66
74 libsystem_pthread.dylib 0x00007fff6d22640d thread_start + 13

InstaCrash (36.1 KB)

first thing first, because it seems memory allocation related, let me ask: are all your buffers instantiated with a duration?

Otherwise, can you try in Max 7?

When someone (at Juce) write DummyCriticaSection in their code, that worries me :wink:

The ones from the other thread are, in fact all “used” buffers in my patch are (most are @blocking 2 ones, so those have to be allocated deliberately).

There are some buffers that weren’t, but they are from pre-processing parts of the patch which are there for @jacob.hart later on. I’ve gone and added a size to all of them now too to be safe.

I don’t have Max7 installed on my desktop (which is what I’ve been using in the studio). I don’t use any mc. stuff here, so it should play nice in Max7 (even though it’s slower).

can you reproduce the crash easily (combination of moved and things?)
if yes I’m happy to test

1 Like

which device? As I say, if you can find reproducible steps, I can try on Max7

I can’t easily reproduce it. I’ve only had two crashes with this patch ever, both pasted in this thread.

That being said, in playing now again when I enabled the M4L device (Cloud) Max kind of hiccuped a bit, like if it was dropping frames or spiking CPU or something. I didn’t have the CPU monitor open so I can’t see if that’s the case but that’s what it sounded like.

This is the patch/dependencies:

The issues I got was from enabling the Cloud one.

(I’m wondering if this could be from how M4L devices “freeze” everything (even the scheduler) when turned off, and this device has lots of buffer-based processes going, that maybe something “dirty” can happen when/if that process is paused/unpaused)