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:
parent
85ce690475
commit
f75add6173
@ -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);
|
||||
|
Loading…
x
Reference in New Issue
Block a user