fl.timemedian~: memory stamping crash after NaN input

[Owen Green]

(This is the crash we were in e-mail contact about the other day. I have new info)

What?

Under quite specific circumstances fl.timemedian~ appears to be the cause of memory-stamping flavoured crashes that manifest as failures in tlsf_free,e .g.

0   AHarker.fl-interval-            0x00000001166ae1dc tlsf_free + 268
1   AHarker.fl-interval-            0x00000001166b4f81 FrameLib_LocalAllocator::clear() + 97

The conditions seem to be that:

• fl.timemedian~ has some NaN input (obviously werid for sorting)
• Then it receives 'valid' input:
  • this needs to be dynamic. Just feeding NaNs and then a repeated frame of valid numbers doesn't cause a crash.

Expected

Not crashing (I guess NaN-in -> NaN-out, which presumably means that they'd persist for ever as they don't get sorted? Or filter NaNs)

Reproduce

Patch below. Turn audio on, at some point press the message box with a 1 in it, enjoy crash.

----------begin_max5_patcher----------
996.3ocyXEkaaiCD8a6Sw.8SaCTcEkrrr6G8m8Br+uonfVhJlARjBjTYSPQM
5cnWfdV5QYOI6PRYGmFaA4X2VCXKYQMjy7dyiCI8mGOJXo7dlN.dO7OvnQed
7nQtlrMLp64QA0z6yqnZmYA4x5ZlvDD5emgcuw09eon5U.W.FdMCpYEbp.tV
7ee8aPMUvKYZiFn3mpJYN0HUPtToZaLbov1MoYESAxk2xxQCe6GvgnVpd.zF
ZcCWbCHKAsDGZsTYbi6O99JrclFvA.6LrrsrDGhUz6veyrcojU.BpPCuVHMn
SJeCbEUTXsVbEXT3q3V+as0HciLcYEKDJdPPq44XWZZMvq4SXvssZCTVwaZ5
rFgWqHeE016Pz4F3NZEu.JUTLJKjLs3UFHm1pYPtkbdy0hqE+36WK1vcUbAK
W1JbD37tFEs0bQEy3XaRWiMTStEreRgriOaQhljFBymDEBIISs2HwYShfO10
EdgKsfD5aIyBdbvkslMidTWqZyCULm0A1F9x3w1Kgmnf3uaQ8.xSNrGbjnaZ
DwAoYYtaoQ1awQG.eS+UhOKfvrqQJ5EDKuIWVIUcIGWTauD08qsw8d.aR1BO
XWXSojYtq6lK2xojfmi9CjbS1ouRwNwVz1v5YwlBEiEL2PuvJo1DwVEsgo9D
SXmdrK05cn4gFlevCBB8e4VU8GOKIfZlVSug8LAFNy1N6duYk3Cy1yc4kzYN
NO0MyINd+Bqr8SsjCB9yDhEr+Ec+y.bY0DiDMb8wNahfZJKXSbY7YQ8g43KO
LiKn3WOYMhD7ywlw6f+z4dAebu3mj7Gh.NjL+ngaxb2pBjENTG6JpbPzdgkt
MPzwJtiybvMNwC2dmPShNR3dFKic.DWnavs3XXqOdbmsSZdVRe3dw9g8z9fc
ncxmjZ1TMO72AafS2KU3FJdAE45zAI9I6Y8pClewUj6cqOfxe.00R7aevuv1
gfb5EGju5kC4Mk35uT9zKNHiSfXJ7XBqgzmT48XVEuaOwyWzGzSt3fNdXqBY
8Z3cULwMlUP7KM02wBjrdKzelwu60tCr8SGV1En11eJonksp7MCdWEX3wHs.
OMLWPsm8bGarqNYMZu79Pcz7A3HrV.P1ZiTUvbmMH5WtimteGSNIGmNDpM4L
PsSGH0dp9IY.94orcMunQhEW5Dmj3T2l9Vj4tMOa6Sm6j9PBUxPB0zXeA8Ge
5bKShGPnl40mmjeHCgShOCxDR7v0Imlih9c4nAVB4o9wWal1zbGSo6L14Bbo
oa8+qGYgtG4B+it+aj.E6N9F6c6DNfpvEcL3JNsJ+R.2OyuGhfZIpAEs7NYH
54uL9+wTJeOW
-----------end_max5_patcher-----------

[Alex Harker]

What do you think the correct behaviour is If I put a NaN in? NaNs are lo NaNs are hi NaNs are zero NaNs are optional replacement value (I don't really like this much) NaNs are NaNs so whatever doesn't crash - you're own your own for correct results, mate

Please vote.

[Alex Harker]

Coding one of these solutions is easy, but figuring out which one makes my brain hurt...

Also - apply this to all the other fl.time....~ objects

[Owen Green]

The last one is the most consistent with the FrameLib ethos, IMO. We can filter NaNs out ourselves

[Alex Harker]

OK - now I need to figure out which of the first ones is easiest to implement.

[Alex Harker]

This no longer crashes. NaNs are considered high which is not perfect, but it makes it more likely you'll see a NaN in your output and hence realise something is wrong if you do feed them in