Metadata with long number causes hard crash

[bbulkow]

With a metadata like this:
"meta": {
"name": "bench-1",
"base_x": 40,
"base_y": 0,
"base_z": 696,
"ry": 230
}
we had written some math that caused the value 229.999999999997 (or similar), and that caused crashes when playing different files. It didn't crash immediately, but it did crash hard (required force quit).

[bbulkow]

We have worked around the problem by not loading metadata like this.

[mcslee]

Making sure I understand here. Was the issue that the metadata was not 230 like you show here, but that you had 299.9999… in the spot where 230 was? Did you get any stack trace on the crash? What happened? The core libraries don’t do anything with the metadata other than put it into a hash map to let patterns access from the model, and they’re in the map as strings, not even as numbers. To debug this would require looking at who accesses the value and how. Do you know what pattern is running when the crash occurs? If it was a stack trace free crash I wonder if there is an infinite loop being created in some pattern or effect that doesn’t like this unrounded value? Need a little more to go on to help debug here, and I suspect the issue is on the pattern/effect side. Le sam. 19 nov. 2022 à 00:08, Brian Bulkowski ***@***.***> a écrit :

…

We have worked around the problem by not loading metadata like this. — Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAER6WQUPX52X37RDBTKMLDWJCDG5ANCNFSM6AAAAAASFGBTAQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[mcslee]

This very likely will have been these lines:
https://github.com/squaredproject/Entwined/blob/master/chromatik/src/main/java/entwined/core/CubeManager.java#L61
https://github.com/squaredproject/Entwined/blob/master/chromatik/src/main/java/entwined/pattern/misko/SyncSpinner.java#L42

Number parsing methods like Integer.parseInt() can throw unchecked NumberFormatException and in this case I'd bet that's what happened here.

Would be safer to have those method use Double.parseDouble() and cast to an integer.

[mcslee]

FYI also a best practice to surround with an explicit try/catch when using number parsing methods, just in case you get garbage strings in there somehow. I find it annoying that they made these unchecked exceptions in Java. It's a pretty easy way to get an unexpected RuntimeException

[cswales]

@mcslee - Yep. Fast coding and laziness on my fault. Apologies.