Calling `get<X>` for an unset buffer attribute crashes Max

[weefuzzy]

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.

flucoma-max/source/include/FluidMaxWrapper.hpp

Lines 1096 to 1109 in 38b6525

	static t_max_err get(FluidMaxWrapper<Client>* x, t_object* /*attr*/,
	long* ac, t_atom** av)
	{
	ParamLiteralConvertor<T, argSize> a;
	char alloc;
	atom_alloc_array(argSize, ac, av, &alloc);
	a.set(x->params().template get<N>());
	for (index i = 0; i < argSize; i++)
	ParamAtomConverter::toAtom(*av + i, a[i]);
	return MAX_ERR_NONE;

Repro:

----------begin_max5_patcher----------
339.3ocqS1saBCCCE95zmhnbcGpocEP6UYZZJzFXA0lTkeXcBwd1WhSJhMXa
HD2zHaeZO9ywceFhrRMxMD7S3mwHz9LDBRERfRwHROaroiY.Yjdtwv1vI4wZ
RWuxY63VnJMkUzBZUq19P8jxnL6GC7ncDB9kToAls4MgbyqZdiMVktb4rhbb
YcU3nt.BJmUb7c7FKjS9VFxcHKK7H+1.wxGAqIa7eSkS2b8HVciHVUFnhtXQ
3XN89inj+tu+Niv0cNQ6rUt0Mp9Akg+4kIs7bRo+No4WGskTfVZw7+FW5I3B
JHcB4O2TAaB4+9LHc8EarTaioG8okarBIyJTxSzTG0bwo705ieQ.W7O9PiZN
CO1vvNt1jDCV3uL2pzgvk4PnPFCqgPMemXRObWQXZ+T25G4NMzVjw4ORhupp
kqkNQZz5gyaIrnHY9eDFXQNf8orCYewGTa+J
-----------end_max5_patcher-----------

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

[tremblap]

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 ) so I reckon if there is a flag in the returned atom that we could poke at to know it is invalid/null pointing?

[weefuzzy]

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.