- attached Max_2017-09-21-222810_Owen-FluCoMa-Box.crash
- edited description
Crash with 0.4
Issue #19
resolved
I was deleting some cables with the audio on. FWIW, I do have an absurdly large framesize coming through fl.source~, which seems to be where the sorrow was.
Edit: I did it again.
Comments (6)
-
reporter
-
repo owner
These are two different crashes, as you've noticed. I would be very interested in the first one being reproducible, as I am fairly sure that the other one represents an object level error.
The first crash, however, is in code that either looks like it couldn't possibly crash, or is in the framework. Can you try to make it happen again in a way I can then make happen? The other one will get dealt with in the other thread.
-
repo owner
BTW - for connection issues it is possible that threading is an issue, in which case you may hit a thing that only exhibits one in N times - that's fine for me to work with. The main thing is something I can hammer on until it breaks.
-
reporter
- attached otg.fl.wobble2.maxpat
It seems to be reproducable if, in the attached patch, you try and connect anything from fl.fft~ to the fl.times~ below, whilst the audio is on. All those times~s were a complex multiplication abtraction.
-
repo owner
Thanks. I will get onto this as soon as I have unbroken everything else that I have currently made broken....
-
repo owner
- changed status to resolved
Actually this one was easy and was an object-level error, but there will be more conversation to have later. The input to fl.vmax~ is empty and the STL function that gets called crashes under those conditions. Right now I've fixed vector objects to produce empty vectors as outputs (later when I get into object features I'll ask people if they prefer this or default values). Anyway, crash gone for the next one, but my refactoring of the connection code has brought some old punishment crashes back on my current build.
- Log in to comment
