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…
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…
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
Something is messing about with memory allocation… have you tried it in Max7?
Hmm.
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.
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.
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
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.
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).
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.
(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)
