Instacrash from fluid.bufcompose~

I think this has to do with the buffer~ threading stuff from TB2, but I got this when changing the attribute on fluid.bufcompose~. I went to set it to @blocking 2 and Max insta-crashed on me.

Prior to that I was getting error messages as follows:

fluid.bufcompose~: Process() called on empty queue
fluid.bufcompose~: Process() called on empty queue
fluid.bufcompose~: Process() called on empty queue

So I think it was trying to access a buffer that wasn’t yet ready from one of the TB2 objects, but I don’t know.

I can recreate the error above (just by removing @blocking 2, but I’ll see if I can narrow it down to a reproducible crash.

Here’s a crash report:
bufcompose blocking crash.zip (40.0 KB)

I don’t think bufcompose is blocking2 compatible. I’ll check this if @weefuzzy has not replied

It takes it, and I’ve been using it for a while. It also complains if the corresponding buffer~ isn’t the right size.

Yes, bufcompose is meant to be fine in @blocking 2. Meanwhile, there haven’t been any deliberate changes to threading in TB2, so stuff should work how it always did.

Process() called on empty queue is a ‘this shouldn’t happen’ style of error message, so clearly something screwy is going on. Are you triggering very fast, or setting parameters from the main thread and triggering from the scheduler? It’s not trying to access buffers at that point, so this isn’t the cause.

The crash itself is Max dying when it tries to allocate memory for a pop-up menu. This could be due to memory stamping caused by whatever this badness is (but equally, might be a coincidence).

FWIW, crashes that are hard to reproduce don’t qualify for the perjorative of ‘instacrash’ in my not-so-humble opinion :wink: Anyway, two separate things to reproduce here maybe:

  • The conditions that produce that error message
  • The conditions that lead to the crash

I guess I use insta-crash to differentiate from a hang, or a pinwheel followed by crash etc… So like when I do something and then the app immediately disappears.

You know me and speed! I was in the main patch, but the example below, isn’t fast (500ms). Wasn’t changing attributes or anything weird like that. Actually…it could be that pesky startframe thing again.

Ok, here’s a bit of patch that reproduces the Process() error consistently.


----------begin_max5_patcher----------
3359.3oc0bs0aaiiE94jeEBF8gc2wIfjRjhbepykc5.rsyVrsKFrXvh.YaZW
0JKYHQmKyfo+1WdQRVxVWnbjRxjGbXjDEOmOdtyiyue4EyVjbOOalye24Wct
3he+xKtPeI0EtH+uuX11f6WFEjoerYhjMah3ylat0tfzfsbAO8FdbvB40kOB
H+dI6EQbg3gcby6eVXrXly+qblhkeJLdyMo7kByC.QdWCl6PfpOMiUeVNk38
aCikuRMg.yuX3JMYkr3yWgIyN7jlU27npK9GWdo5i4Vxlw76juxh2mfeulFm
I40zDGL.LqMlbQP7Fa3RHvWyrtZ1D0FahNkMcoSNalFDuJYqjFAcvoVtcB8X
peQIClQQ3ImQWre8Zd5Wc9bRrTpNy76GtNHbcqr85nj.wr4VrSiHTM.vz6wP
W+tQfFjnQflQ.z3i.Wc0UB41dVHOV375rfs6xjzJcLfAex034NtXM+CongCC
dOYvv10KWlUv+LGDXDA.jlygX5fA.W3SF.jIBDk..BNtH.KGAXCFAvtSNBry
QNJMXo3pe76e2UqBDAOZi7Ea4Pugyvsn5Cqtn7zb1LmOuX15vH9s7zrvj3JO
8EyB1sqxkunxTTfymSzuH57xKEFatDr7Ro7aCKlOt7pAoRVWH468oZvY18jB
kU0qIYEOMdeXoUa81TNIo2PhkgOjsKXoYxp8shae.LMhKPfFD8c0PJ1qBXJ2
v2Dkr7K7UUh+PtssiGGFuKkmIsoEHxo8xauhuNXej3l0IwhrveSSAP0Kug6u
NmBa7lJdPS9eaZXPTICrIMbURrhHpsSntbwxIETvFMhpLi9IhC10vjkRFRXo
kapTc2msHHUsQkGLFp3lhjjn52pbdQ70h7auKLN9HTTjrq8alFt4ScL2EIxa
tsq2s9NY2rO1b2ajxDhaxBtsNZKBhhx0Zq+5uOHNbaffKBMaAHP4MMAj9ork
oIQQ03Wyctsg6rRJiujeW3JwmzKTUgA4iGtqPHZV4t7pvM7LQ8qIB1jU+JYh
GLfdkKseQtN7MB91cQRtn9CH0NByDYeJ4tr7GrPPqJ.bH58p5zUMAV65cYJ7
HygAK+hSnSX0adhgvRifsYHjZr7Yb56chmuViC7jP.PypOiiiG7hB+.4FYNS
.QZMJKXCuQDQpekJYvfXmWAebnBh3q7GhLtG78OaXwC+z.KcHmHbVzqXh1e4
bSJCyqm4P2BN49Q8.8iPvVPHZ6Hj6SCBIMtYitzfAGDjVIe4yAbf9sCNnmFv
IRZia8dos+HGPmvi5AsUpgYJj.87kZXO+la.NPGOGhiuCUFAoL+QYpzxHEjY
PcHn7GkUYHwDcJw6rs+PfO61e9FGXupUVZOFxzoofXFiymAdvnO63A+9coNu
JD57MN+kWEhb9aRin+0QwItGtkjYrGddo3EesprkNuBM2QFXmn5kfycLdqd7
.lKz31xDi+4AXfmc4o0Q6CWc8h8qWlrcWRF+qNuNKYe5RdQoBTHXXrN+piph
jjd0nZlzRl5OTwNk0i5ZQnBkEWvVv10Do.87M5SXO+gJ7agRqP83Ir.hpFUU
efDFXxgV+KL7rEHodOMXjlP5GErisMgO5V9Y6bMnYt1uCttpvjTEYKOtd1f5
WU7J98isNqgFl0M.P7M.fmsHPK5F9cDoH3wh.GJ8QTXbaIzpYN08aFZL1jxk
MJhsUZ2oJiVwRUkGTkZo5AsZq4rnBfETgx0n5AmDp.grkJ.SHUnREyJpPEU4
zREPa2QfSIUfrgJnSIVvrbGoPLdRnhhs6dohBxcRnBkMdqnBp2DRE5WtMxEd
zolJrQGweJkKX1Z0BMk1NY1Z0RUKtoiJ.1Z6bJ0QJXwGCUjewhyAZlpX+qtw
bvF2DHDogK1KLAAT8fsFTA32DkrHH5npl2T84u7.wMNGhXY1R5jiNjqTw4Jq
SYJOwIYTTq3og2lIU3e8B0AXIicyA08oN1XpQcbDjHpt6CbomwYt1xoN6NAv
kBe9pCBTBXEcjwqWyCTGtXVADpxiLgudcl9oOjhIBSjO7ZQlDyjHg4BDOYxN
SI5ZpIBwe3M0.1a7P2506n4ZcTuvFcTTit5km7VY4zJZzay7P75uYdzur54.
X39isSkiAmFIQMe3sXaBWw+8I3rsqD1pUBNFqDzlUBLFqDwhUxkNBqjK0hUB
gGgUBgsXkHmJQXDEOpqITKxQcKwQcJwocIQ6cHwwcGg1in4jhOR7+PCFreUX
xGzGy+MuiGu2nRUzLB0ghEaVGFEsLIJ4jlDoPqel4tkMjQwy9qNfqQLOHjJg
kqcgt9Hhdjb.FWMxPybfESxC6w.H0i5QP9dX8HJxE6pFANZZnCqE.xLq.fQA
dlQxKIsYAqNs.kOAsAF+JmM+tzjcIok82w0trxmeuHYSZvpv7RR.p4uedtjT
p7tGe.8y1JAzvh4TUxqby3s6WF7X2.JItV1CrDWpuKPKwdpO.SolQTO2FmV4
t.AKWD0yRT+3aFYdSSxlPtJYMN1yGCc0jNhICYwLBCADVMhXV01tQpD+u1wi
c9fp3xefuMbQRzpCdyVro1Jv.dPelFRXXOeMaR8PLe8ZICYnXdAKWJI3Zy0E
Iku0aBdEXkRiv6HhiGw2d7T8oRH0rm.fTpYj7sfP0malbxKUnX8YijHfd8fx
PMLJST..5UexJ+954cSXrxtEuTPxkgfDCXVnghpJQLJJDuSF8dWJDUazJYHE
fi1OK5wpesnnKOZB58eq3F8z.CfrpFTye1TgsdZSoNLCq7cXzl77AZlWw6tc
qCaZdt1UaMXVSip9RaPq0N6ZyVFwktpOLQ8YjHWDoMBrY5RL020RMN8bK9X7
Tw9kO9iCPTlVgRKCXpt3ox4t1dBDAwDiwMkji1DA64WQvNStO6ATzjd.TE2j
wqhR3Win9EQP0tdvO8vpzjM73Opw0VTGfDWotkdey2ivX4i.rd0Fv.ehFO.D
rKz7Jj68HK7g4QfPfIlNFh3owWLCJMvLlh35rZCWZuXNqWo7SUFm+nhQ9fYZ
WluwHqKK2lm5RX2wQ5rFSPK8ge5nyRltqvvxMW2znNDceCOleaPqBs1gVMIz
ZK87TaNNWV861KDRbsCI1S8qPKEB.4iFcx5GJ6F8WPD0aBBi+pkTkTJszx4o
iFeRK6tPo4itHtSjMg4BTG9XRnIzKJh5elEEthmNDYqinllMPzpc5F8FYoMg
lynp2YOl30a4qFldnsX.YRMqIymKM79khznGA0OpDj5aZ7W6tlKCy7wiQ9ZL
4reNYEO67B44bBR3E.COHSHSsC7ed+1EcSLMYE4TmlS.o89vkh9wpm88y2q9
V1IdwEswGVlriae3FGpZMyU8SioL77AxeLXg8rhktGaRxoWqHiJSIiYewfCf
t43IZH0go0vwGq7eCiwHb1N1Tbk4s6CMyvyEpyZzK+XUFSV5+rsmCV5ILPye
I3V95jzseczQ3gGUH3Z7HwbqBR+xUwpu4rWoqWQWLWyEzvqTszurb9kE1mpI
3QnzcvdD8F8RbL5ksqdINZv5fs0ptrvBVWo8QQR4y4svD.j2JNiwqBMj3Lw8
TZsCEW+jAiWY15nHvf+jICd7gdrHhK87YN6xuKI4KyZ87H5GFFIQtv3uLbKR
D77ZeNBUYs7UKAe.szMtKAH0y59PClN6US4AFzOidREUs679Z7Tw5ewZrhC8
OsSEbObRH5G2s5n9cJawRdh44tlynnl7ESNY+hp0ddtCVJREJQ+gPebsQ.Lu
7Frfwbo94i7oVjf.oLXCboAnBktwiu1FbOo7+HLVvSGAvfJNuZPAfVO+F+b8
9myiSPwvU9huYSVdHWLhU2SfxjvnuOTqCSG69cpRaOTbB8mNpCq29TUOlMuw
QOgd5szl+HIUUW6vtcwpekAssnaU5ouQutFltB+6h1yuBNnS3P0Uh94m.9Ai
QrQ2DTNAllbW7fovmFijFJ76eHX3DH.wvlSw2220EYz1PPo25wm.eSJmeFTn
F8JKEGjnB3Y7It2IsrEKBFL4Q8.DhoHgDfj3zPIgAY3wmF+27UCl97Ki9EVl
w.H2iwXSe+WdTTxccShm1ocXF.P6zKMBaZREeJjpCoWNGrGdxX.zeFY.8wW7
ljnyPDorrGXYjPXS+.U0I3nPf61mtKhOnfS8.l3ZPX.gokgQTLAQsLBM+xtD
zChklMz11TVOFUfOkujGda2mbWSxDkIqcf3.UaIwwg3LonnDKr1iOwSZPik6
HvOu6nkRqL2NyC8oQJJiGuJ6klGjCfb25dG0Mq9Pfu4bl7H.VdSn6Cw8l29S
CTKB10mcvJUw5sAhDm2pxBc1ns9YB958QQhgc.KpuzJ9ZzgTFcupT.9zNkeg
TLFZJiNw020zo7DoJIYbAUCS8zvSHpO0Dbhao3uKh4xnuTxuWn9d69R56Kvc
pp47f8jjKo2VOExX.SfgRoIu7S6l..tv5MX8QZT+PXp3Am+wljY8TbLfR1Pm
vqatHgzDQ9gZXkix95N9gCrlu5bs7e22K+iK++7tuT.I
-----------end_max5_patcher-----------

If you add @blocking 2 to the p extract-FCM-data subpatch, it goes away.

And for good measure when extracting this part of the patch I got another crash (that happened instantly).

compose crash2.zip (36.2 KB)

p.s. running that patch for a few seconds gave me a proper instacrash…

With some nastier comments about fluid.bufcompose~ in the crash report:

crash3.zip (27.9 KB)

Fair enough

Just cooking so haven’t run it yet, but the likely culprit is that parameter changes are coming through on the scheduler but the object is on blocking 1. Why that’s leading to no params getting queued for the job is another matter (worst case, they just wouldn’t be the values you expect). So, yes, blocking 2 or defer-ing the parameter updates should fix this (but there’s a bug somewhere, because it shouldn’t crash)

Definitely a memory stamp: same species of crash, but somewhere else (in the C++ standard library this time)

1 Like

I’ve had this kind of JIT code in place for ages, though I tend to always run it in @blocking 2. I’ve only been turning it off to see what I need to resize the buffer~s to, and in doing so I got these errors and then crash.