[PD-dev] how to dinamically allocate t_atom & t_float size?

[Christof Ressi]

> I'd strongly advise to avoid it in general.
For general purpose code I would agree, but for realtime safe code we 
want to avoid dynamic memory allocation and careful use of alloca() is 
perfectly fine. But there are caveats.

In fact, we had a crasher in FFT objects which used temporary buffers on 
the stack. Users tried to do a 100 000 point FFT and it would crash on 
Windows. There are at least threee ways to solve this problem:

a) conditionally switch to malloc() beyond a certain size (don't forget 
to free the buffer :-)

b) use a pre-allocated buffer in the object

c) use thread local storage

> In fact, the next time I get on a Windows machine I bet I can create a 
> trivial Pd patch to blow the stack using only `[list prepend]` and 
> `[list fromsymbol]`.
To elaborate: The limit for ATOM_ALLOCA is 100 and the stack limit is 
1000. On a 64-bit system, t_atom takes 16 bytes (including padding). 
This means we could have up to 1,600,000 bytes on the stack before Pd's 
stack protection kicks in. The default stack size on Windows is 1 MB, so 
it would blow up.

Christof

On 04.12.2020 07:30, Jonathan Wilkes via Pd-dev wrote:
> > You can avoid the free() if you HAVE_ALLOCA with
>
> >        t_atom* at = (t_atom*)alloca(ac * sizeof(t_atom));
>
> If the user can control ac, then you have likely introduced a 
> potential crasher just to avoid a call to free.
>
> Systemd had a cve from using alloca awhile back. Pd recently fixed a 
> crasher due to alloca. In neither case was alloca necessary.
>
> I'd strongly advise to avoid it in general.
>
> In fact, the next time I get on a Windows machine I bet I can create a 
> trivial Pd patch to blow the stack using only `[list prepend]` and 
> `[list fromsymbol]`. If so it will be 100% due to alloca, and an 
> ostensibly defensive use of it at that. (Have a look at the code for 
> the ATOMS_ALLOCA macro if someone wants to beat me to it.)
>
> Best,
> Jonathan
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20201204/a4250cbf/attachment.html>