Obviously noone ever really used BFlattenable objects with our BMessage, as it

was pretty broken. It would store the address of the buffer in the message
instead of the actual data. Funnily, since it was completely stack based before,
it would have stored the address plus the actual data (minus 4 bytes) as that
did reside directly after the address on the stack and the original buffer
length was still used. This corrupted the data, but still "worked" for MDR
because it has fault tolerance, loosing only part of its flattened StringList.
This broke however when switching to a heap allocated buffer for large sizes,
as then the heap address plus some random heap data was added to the message
instead of the actual buffer. Sure interesting that nobody noticed that before...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26984 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Michael Lotz 2008-08-15 20:55:06 +00:00
parent 85ce690475
commit f75add6173

View File

@ -2405,7 +2405,7 @@ BMessage::AddFlat(const char *name, BFlattenable *object, int32 count)
status_t error = object->Flatten(buffer, size);
if (error >= B_OK)
error = AddData(name, object->TypeCode(), &buffer, size, false);
error = AddData(name, object->TypeCode(), buffer, size, false);
if (buffer != stackBuffer)
free(buffer);