Open weefuzzy opened 2 months ago
It crashes also in the latest public release... if I understand the problem, we don't deal with unattributed buffers well. now, a native-yet-unacceptable solution for that is to do like native objects and bail at instantiation (like peek~
) but it would make a lot of object useless...
our current code is dealt well with by attrui
(i.e. source
Yes, no need to bail – we only need to fix this specific behaviour. It's also not a question of us querying a returned atom because this is Max choking on an atom that we're returning.
This is resolvable with some experimentation I think. We can try (1) returning ac = 0
and a null av
and see if that works or (2) just returning gensym("")
for unassigned buffers.
Please tell us what you were doing! You can include code and files by drag and dropping them into the text area.
Thanks to the magic of obex, we can retrieve object state via
get<attribute_name>
messages. The machinery for this ultimately calls our own custom getters.When we have a buffer attribute that hasn't been set, that getter is essentially returning a null pointer wrapped up in some atom machinery, causing Max to crash downstream when it tries to dereference the pointer.
https://github.com/flucoma/flucoma-max/blob/38b652577a30f8f5824c0d9b943272ee4cdce9e5/source/include/FluidMaxWrapper.hpp#L1096-L1109
Repro:
What was the expected result?
At a minimum, we don't cause Max to crash.
Open question on what the output should be for an unset buffer attribute in this case: a zero length string? Some magic string like
<unknown>
?What was the actual result?
Max crashes, in a debug build at any rate: it might not crash in release builds, but that shouldn't be a comfort.
What operating system were you using?
Mac
Operating system version
Ventura 13.5.2
FluCoMa Version
Custom build 1.0.6+sha.38b6525.core.sha.98bdc5e3