[haiku-commits] Re: haiku: hrev46866 - src/kits/network/libnetapi
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Thu, 13 Feb 2014 09:15:09 +0000
> From what I understand, the dynamic stack allocated arrays are a GCC
> extension anyway and should be avoided. So why do you not use the
> BStackOrHeapArray in the second chunk of the patch? I haven't read the
> code in context and don't know if it would suffer from the same
> potential overflow problem, but the array is of dynamic size in any
> case, so you should switch it there as well.
The gcc extension is allowing dynamic arrays of non-POD types. In this case,
the type is char which is a POD, so there is no such problem.
The problem we have is when allocating a big chunk of memory on the stack, and
accessing it in a non-sequential way (for example starting to write it from the
end). Our stack guard doesn't catch this, if you write past the protection page
that's above the stack.
I think the second case is fine, because the data is written in-order to the
buffer and the stack will grow. But it seems zlib decompression isn't writing
in-order, leading to the crash.
I'm not completely satisfied with the current solution, as it involves too much
copies of the data (from the socket to a BNetBuffer, then to a temporary buffer
sent to ZLib, then to a DynamicBuffer, then again to a temporary buffer for
sending to the listener). We should refactor the code to avoid this, probably
using a pipeline of BDataIO subclasses to process everything in a stream.
--
Adrien.
Other related posts:
