Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2013 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
2013-12-04 17:06:49 +00:00
|
|
|
#include "SkBitmapDevice.h"
|
|
|
|
#include "SkBitmapSource.h"
|
|
|
|
#include "SkCanvas.h"
|
|
|
|
#include "SkMallocPixelRef.h"
|
2014-04-18 18:04:41 +00:00
|
|
|
#include "SkPictureRecorder.h"
|
2014-03-14 21:22:22 +00:00
|
|
|
#include "SkTemplates.h"
|
2014-01-30 18:58:24 +00:00
|
|
|
#include "SkWriteBuffer.h"
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
#include "SkValidatingReadBuffer.h"
|
2013-12-04 17:06:49 +00:00
|
|
|
#include "SkXfermodeImageFilter.h"
|
2014-01-24 20:56:26 +00:00
|
|
|
#include "Test.h"
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
static const uint32_t kArraySize = 64;
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
static const int kBitmapSize = 256;
|
2013-11-05 15:46:56 +00:00
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
static void TestAlignment(T* testObj, skiatest::Reporter* reporter) {
|
|
|
|
// Test memory read/write functions directly
|
|
|
|
unsigned char dataWritten[1024];
|
|
|
|
size_t bytesWrittenToMemory = testObj->writeToMemory(dataWritten);
|
|
|
|
REPORTER_ASSERT(reporter, SkAlign4(bytesWrittenToMemory) == bytesWrittenToMemory);
|
|
|
|
size_t bytesReadFromMemory = testObj->readFromMemory(dataWritten, bytesWrittenToMemory);
|
|
|
|
REPORTER_ASSERT(reporter, SkAlign4(bytesReadFromMemory) == bytesReadFromMemory);
|
|
|
|
}
|
2013-11-04 16:18:15 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<typename T> struct SerializationUtils {
|
2013-12-04 17:06:49 +00:00
|
|
|
// Generic case for flattenables
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, const T* flattenable) {
|
2013-12-04 17:06:49 +00:00
|
|
|
writer.writeFlattenable(flattenable);
|
|
|
|
}
|
|
|
|
static void Read(SkValidatingReadBuffer& reader, T** flattenable) {
|
|
|
|
*flattenable = (T*)reader.readFlattenable(T::GetFlattenableType());
|
|
|
|
}
|
2013-11-05 15:46:56 +00:00
|
|
|
};
|
2013-11-04 16:18:15 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<SkMatrix> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, const SkMatrix* matrix) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writeMatrix(*matrix);
|
|
|
|
}
|
|
|
|
static void Read(SkValidatingReadBuffer& reader, SkMatrix* matrix) {
|
|
|
|
reader.readMatrix(matrix);
|
|
|
|
}
|
|
|
|
};
|
2013-11-04 20:28:23 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<SkPath> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, const SkPath* path) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writePath(*path);
|
2013-11-04 20:28:23 +00:00
|
|
|
}
|
2013-11-05 15:46:56 +00:00
|
|
|
static void Read(SkValidatingReadBuffer& reader, SkPath* path) {
|
|
|
|
reader.readPath(path);
|
|
|
|
}
|
|
|
|
};
|
2013-11-04 20:28:23 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<SkRegion> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, const SkRegion* region) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writeRegion(*region);
|
|
|
|
}
|
|
|
|
static void Read(SkValidatingReadBuffer& reader, SkRegion* region) {
|
|
|
|
reader.readRegion(region);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct SerializationUtils<unsigned char> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, unsigned char* data, uint32_t arraySize) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writeByteArray(data, arraySize);
|
|
|
|
}
|
|
|
|
static bool Read(SkValidatingReadBuffer& reader, unsigned char* data, uint32_t arraySize) {
|
|
|
|
return reader.readByteArray(data, arraySize);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct SerializationUtils<SkColor> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, SkColor* data, uint32_t arraySize) {
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
writer.writeColorArray(data, arraySize);
|
2013-11-05 15:46:56 +00:00
|
|
|
}
|
|
|
|
static bool Read(SkValidatingReadBuffer& reader, SkColor* data, uint32_t arraySize) {
|
|
|
|
return reader.readColorArray(data, arraySize);
|
|
|
|
}
|
|
|
|
};
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<int32_t> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, int32_t* data, uint32_t arraySize) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writeIntArray(data, arraySize);
|
|
|
|
}
|
|
|
|
static bool Read(SkValidatingReadBuffer& reader, int32_t* data, uint32_t arraySize) {
|
|
|
|
return reader.readIntArray(data, arraySize);
|
|
|
|
}
|
|
|
|
};
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<SkPoint> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, SkPoint* data, uint32_t arraySize) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writePointArray(data, arraySize);
|
|
|
|
}
|
|
|
|
static bool Read(SkValidatingReadBuffer& reader, SkPoint* data, uint32_t arraySize) {
|
|
|
|
return reader.readPointArray(data, arraySize);
|
|
|
|
}
|
|
|
|
};
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<> struct SerializationUtils<SkScalar> {
|
2014-01-30 18:58:24 +00:00
|
|
|
static void Write(SkWriteBuffer& writer, SkScalar* data, uint32_t arraySize) {
|
2013-11-05 15:46:56 +00:00
|
|
|
writer.writeScalarArray(data, arraySize);
|
|
|
|
}
|
|
|
|
static bool Read(SkValidatingReadBuffer& reader, SkScalar* data, uint32_t arraySize) {
|
|
|
|
return reader.readScalarArray(data, arraySize);
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
}
|
2013-11-05 15:46:56 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
template<typename T>
|
|
|
|
static void TestObjectSerialization(T* testObj, skiatest::Reporter* reporter) {
|
2014-01-30 22:16:32 +00:00
|
|
|
SkWriteBuffer writer(SkWriteBuffer::kValidation_Flag);
|
2013-11-05 15:46:56 +00:00
|
|
|
SerializationUtils<T>::Write(writer, testObj);
|
|
|
|
size_t bytesWritten = writer.bytesWritten();
|
|
|
|
REPORTER_ASSERT(reporter, SkAlign4(bytesWritten) == bytesWritten);
|
|
|
|
|
|
|
|
unsigned char dataWritten[1024];
|
|
|
|
writer.writeToMemory(dataWritten);
|
|
|
|
|
|
|
|
// Make sure this fails when it should (test with smaller size, but still multiple of 4)
|
|
|
|
SkValidatingReadBuffer buffer(dataWritten, bytesWritten - 4);
|
2013-11-08 19:22:57 +00:00
|
|
|
T obj;
|
|
|
|
SerializationUtils<T>::Read(buffer, &obj);
|
2013-12-06 20:14:46 +00:00
|
|
|
REPORTER_ASSERT(reporter, !buffer.isValid());
|
2013-11-05 15:46:56 +00:00
|
|
|
|
|
|
|
// Make sure this succeeds when it should
|
|
|
|
SkValidatingReadBuffer buffer2(dataWritten, bytesWritten);
|
2013-11-08 19:22:57 +00:00
|
|
|
const unsigned char* peekBefore = static_cast<const unsigned char*>(buffer2.skip(0));
|
|
|
|
T obj2;
|
|
|
|
SerializationUtils<T>::Read(buffer2, &obj2);
|
|
|
|
const unsigned char* peekAfter = static_cast<const unsigned char*>(buffer2.skip(0));
|
2013-11-05 15:46:56 +00:00
|
|
|
// This should have succeeded, since there are enough bytes to read this
|
2013-12-06 20:14:46 +00:00
|
|
|
REPORTER_ASSERT(reporter, buffer2.isValid());
|
2013-11-05 15:46:56 +00:00
|
|
|
REPORTER_ASSERT(reporter, static_cast<size_t>(peekAfter - peekBefore) == bytesWritten);
|
|
|
|
|
|
|
|
TestAlignment(testObj, reporter);
|
|
|
|
}
|
|
|
|
|
2013-12-04 17:06:49 +00:00
|
|
|
template<typename T>
|
|
|
|
static T* TestFlattenableSerialization(T* testObj, bool shouldSucceed,
|
|
|
|
skiatest::Reporter* reporter) {
|
2014-01-30 22:16:32 +00:00
|
|
|
SkWriteBuffer writer(SkWriteBuffer::kValidation_Flag);
|
2013-12-04 17:06:49 +00:00
|
|
|
SerializationUtils<T>::Write(writer, testObj);
|
|
|
|
size_t bytesWritten = writer.bytesWritten();
|
|
|
|
REPORTER_ASSERT(reporter, SkAlign4(bytesWritten) == bytesWritten);
|
|
|
|
|
|
|
|
unsigned char dataWritten[1024];
|
2013-12-13 19:45:58 +00:00
|
|
|
SkASSERT(bytesWritten <= sizeof(dataWritten));
|
2013-12-04 17:06:49 +00:00
|
|
|
writer.writeToMemory(dataWritten);
|
|
|
|
|
|
|
|
// Make sure this fails when it should (test with smaller size, but still multiple of 4)
|
|
|
|
SkValidatingReadBuffer buffer(dataWritten, bytesWritten - 4);
|
|
|
|
T* obj = NULL;
|
|
|
|
SerializationUtils<T>::Read(buffer, &obj);
|
2013-12-06 20:14:46 +00:00
|
|
|
REPORTER_ASSERT(reporter, !buffer.isValid());
|
2013-12-04 17:06:49 +00:00
|
|
|
REPORTER_ASSERT(reporter, NULL == obj);
|
|
|
|
|
|
|
|
// Make sure this succeeds when it should
|
|
|
|
SkValidatingReadBuffer buffer2(dataWritten, bytesWritten);
|
|
|
|
const unsigned char* peekBefore = static_cast<const unsigned char*>(buffer2.skip(0));
|
|
|
|
T* obj2 = NULL;
|
|
|
|
SerializationUtils<T>::Read(buffer2, &obj2);
|
|
|
|
const unsigned char* peekAfter = static_cast<const unsigned char*>(buffer2.skip(0));
|
|
|
|
if (shouldSucceed) {
|
|
|
|
// This should have succeeded, since there are enough bytes to read this
|
2013-12-06 20:14:46 +00:00
|
|
|
REPORTER_ASSERT(reporter, buffer2.isValid());
|
2013-12-04 17:06:49 +00:00
|
|
|
REPORTER_ASSERT(reporter, static_cast<size_t>(peekAfter - peekBefore) == bytesWritten);
|
|
|
|
REPORTER_ASSERT(reporter, NULL != obj2);
|
|
|
|
} else {
|
|
|
|
// If the deserialization was supposed to fail, make sure it did
|
2013-12-06 20:14:46 +00:00
|
|
|
REPORTER_ASSERT(reporter, !buffer.isValid());
|
2013-12-04 17:06:49 +00:00
|
|
|
REPORTER_ASSERT(reporter, NULL == obj2);
|
|
|
|
}
|
|
|
|
|
|
|
|
return obj2; // Return object to perform further validity tests on it
|
|
|
|
}
|
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
template<typename T>
|
|
|
|
static void TestArraySerialization(T* data, skiatest::Reporter* reporter) {
|
2014-01-30 22:16:32 +00:00
|
|
|
SkWriteBuffer writer(SkWriteBuffer::kValidation_Flag);
|
2013-11-05 15:46:56 +00:00
|
|
|
SerializationUtils<T>::Write(writer, data, kArraySize);
|
|
|
|
size_t bytesWritten = writer.bytesWritten();
|
|
|
|
// This should write the length (in 4 bytes) and the array
|
|
|
|
REPORTER_ASSERT(reporter, (4 + kArraySize * sizeof(T)) == bytesWritten);
|
|
|
|
|
|
|
|
unsigned char dataWritten[1024];
|
|
|
|
writer.writeToMemory(dataWritten);
|
|
|
|
|
|
|
|
// Make sure this fails when it should
|
|
|
|
SkValidatingReadBuffer buffer(dataWritten, bytesWritten);
|
|
|
|
T dataRead[kArraySize];
|
|
|
|
bool success = SerializationUtils<T>::Read(buffer, dataRead, kArraySize / 2);
|
|
|
|
// This should have failed, since the provided size was too small
|
|
|
|
REPORTER_ASSERT(reporter, !success);
|
|
|
|
|
|
|
|
// Make sure this succeeds when it should
|
|
|
|
SkValidatingReadBuffer buffer2(dataWritten, bytesWritten);
|
|
|
|
success = SerializationUtils<T>::Read(buffer2, dataRead, kArraySize);
|
|
|
|
// This should have succeeded, since there are enough bytes to read this
|
|
|
|
REPORTER_ASSERT(reporter, success);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-12-04 17:06:49 +00:00
|
|
|
static void TestBitmapSerialization(const SkBitmap& validBitmap,
|
|
|
|
const SkBitmap& invalidBitmap,
|
|
|
|
bool shouldSucceed,
|
|
|
|
skiatest::Reporter* reporter) {
|
2014-03-10 10:51:58 +00:00
|
|
|
SkAutoTUnref<SkBitmapSource> validBitmapSource(SkBitmapSource::Create(validBitmap));
|
|
|
|
SkAutoTUnref<SkBitmapSource> invalidBitmapSource(SkBitmapSource::Create(invalidBitmap));
|
2013-12-04 17:06:49 +00:00
|
|
|
SkAutoTUnref<SkXfermode> mode(SkXfermode::Create(SkXfermode::kSrcOver_Mode));
|
2014-03-10 10:51:58 +00:00
|
|
|
SkAutoTUnref<SkXfermodeImageFilter> xfermodeImageFilter(
|
|
|
|
SkXfermodeImageFilter::Create(mode, invalidBitmapSource, validBitmapSource));
|
2013-12-04 17:06:49 +00:00
|
|
|
|
|
|
|
SkAutoTUnref<SkImageFilter> deserializedFilter(
|
|
|
|
TestFlattenableSerialization<SkImageFilter>(
|
2014-03-10 10:51:58 +00:00
|
|
|
xfermodeImageFilter, shouldSucceed, reporter));
|
2013-12-04 17:06:49 +00:00
|
|
|
|
|
|
|
// Try to render a small bitmap using the invalid deserialized filter
|
|
|
|
// to make sure we don't crash while trying to render it
|
|
|
|
if (shouldSucceed) {
|
|
|
|
SkBitmap bitmap;
|
2014-02-13 14:41:43 +00:00
|
|
|
bitmap.allocN32Pixels(24, 24);
|
|
|
|
SkCanvas canvas(bitmap);
|
2013-12-04 17:06:49 +00:00
|
|
|
canvas.clear(0x00000000);
|
|
|
|
SkPaint paint;
|
|
|
|
paint.setImageFilter(deserializedFilter);
|
|
|
|
canvas.clipRect(SkRect::MakeXYWH(0, 0, SkIntToScalar(24), SkIntToScalar(24)));
|
|
|
|
canvas.drawBitmap(bitmap, 0, 0, &paint);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
static bool setup_bitmap_for_canvas(SkBitmap* bitmap) {
|
|
|
|
SkImageInfo info = SkImageInfo::Make(
|
2014-04-11 17:15:40 +00:00
|
|
|
kBitmapSize, kBitmapSize, kN32_SkColorType, kPremul_SkAlphaType);
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
return bitmap->allocPixels(info);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool make_checkerboard_bitmap(SkBitmap& bitmap) {
|
|
|
|
bool success = setup_bitmap_for_canvas(&bitmap);
|
|
|
|
|
|
|
|
SkCanvas canvas(bitmap);
|
|
|
|
canvas.clear(0x00000000);
|
|
|
|
SkPaint darkPaint;
|
|
|
|
darkPaint.setColor(0xFF804020);
|
|
|
|
SkPaint lightPaint;
|
|
|
|
lightPaint.setColor(0xFF244484);
|
|
|
|
const int i = kBitmapSize / 8;
|
|
|
|
const SkScalar f = SkIntToScalar(i);
|
|
|
|
for (int y = 0; y < kBitmapSize; y += i) {
|
|
|
|
for (int x = 0; x < kBitmapSize; x += i) {
|
|
|
|
canvas.save();
|
|
|
|
canvas.translate(SkIntToScalar(x), SkIntToScalar(y));
|
|
|
|
canvas.drawRect(SkRect::MakeXYWH(0, 0, f, f), darkPaint);
|
|
|
|
canvas.drawRect(SkRect::MakeXYWH(f, 0, f, f), lightPaint);
|
|
|
|
canvas.drawRect(SkRect::MakeXYWH(0, f, f, f), lightPaint);
|
|
|
|
canvas.drawRect(SkRect::MakeXYWH(f, f, f, f), darkPaint);
|
|
|
|
canvas.restore();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool drawSomething(SkCanvas* canvas) {
|
|
|
|
SkPaint paint;
|
|
|
|
SkBitmap bitmap;
|
|
|
|
bool success = make_checkerboard_bitmap(bitmap);
|
|
|
|
|
|
|
|
canvas->save();
|
|
|
|
canvas->scale(0.5f, 0.5f);
|
|
|
|
canvas->drawBitmap(bitmap, 0, 0, NULL);
|
|
|
|
canvas->restore();
|
|
|
|
|
|
|
|
const char beforeStr[] = "before circle";
|
|
|
|
const char afterStr[] = "after circle";
|
|
|
|
|
|
|
|
paint.setAntiAlias(true);
|
|
|
|
|
|
|
|
paint.setColor(SK_ColorRED);
|
|
|
|
canvas->drawData(beforeStr, sizeof(beforeStr));
|
|
|
|
canvas->drawCircle(SkIntToScalar(kBitmapSize/2), SkIntToScalar(kBitmapSize/2), SkIntToScalar(kBitmapSize/3), paint);
|
|
|
|
canvas->drawData(afterStr, sizeof(afterStr));
|
|
|
|
paint.setColor(SK_ColorBLACK);
|
|
|
|
paint.setTextSize(SkIntToScalar(kBitmapSize/3));
|
|
|
|
canvas->drawText("Picture", 7, SkIntToScalar(kBitmapSize/2), SkIntToScalar(kBitmapSize/4), paint);
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
2013-12-12 21:11:12 +00:00
|
|
|
DEF_TEST(Serialization, reporter) {
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test matrix serialization
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
{
|
2013-11-05 15:46:56 +00:00
|
|
|
SkMatrix matrix = SkMatrix::I();
|
|
|
|
TestObjectSerialization(&matrix, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test path serialization
|
|
|
|
{
|
|
|
|
SkPath path;
|
|
|
|
TestObjectSerialization(&path, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test region serialization
|
|
|
|
{
|
|
|
|
SkRegion region;
|
|
|
|
TestObjectSerialization(®ion, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test rrect serialization
|
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
// SkRRect does not initialize anything.
|
|
|
|
// An uninitialized SkRRect can be serialized,
|
|
|
|
// but will branch on uninitialized data when deserialized.
|
2013-11-05 15:46:56 +00:00
|
|
|
SkRRect rrect;
|
2013-12-02 13:50:38 +00:00
|
|
|
SkRect rect = SkRect::MakeXYWH(1, 2, 20, 30);
|
|
|
|
SkVector corners[4] = { {1, 2}, {2, 3}, {3,4}, {4,5} };
|
|
|
|
rrect.setRectRadii(rect, corners);
|
2013-11-05 15:46:56 +00:00
|
|
|
TestAlignment(&rrect, reporter);
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
}
|
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test readByteArray
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
unsigned char data[kArraySize] = { 1, 2, 3 };
|
2013-11-05 15:46:56 +00:00
|
|
|
TestArraySerialization(data, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test readColorArray
|
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
SkColor data[kArraySize] = { SK_ColorBLACK, SK_ColorWHITE, SK_ColorRED };
|
2013-11-05 15:46:56 +00:00
|
|
|
TestArraySerialization(data, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test readIntArray
|
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
int32_t data[kArraySize] = { 1, 2, 4, 8 };
|
2013-11-05 15:46:56 +00:00
|
|
|
TestArraySerialization(data, reporter);
|
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test readPointArray
|
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
SkPoint data[kArraySize] = { {6, 7}, {42, 128} };
|
2013-11-05 15:46:56 +00:00
|
|
|
TestArraySerialization(data, reporter);
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
}
|
|
|
|
|
2013-11-05 15:46:56 +00:00
|
|
|
// Test readScalarArray
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
{
|
2013-12-02 13:50:38 +00:00
|
|
|
SkScalar data[kArraySize] = { SK_Scalar1, SK_ScalarHalf, SK_ScalarMax };
|
2013-11-05 15:46:56 +00:00
|
|
|
TestArraySerialization(data, reporter);
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
}
|
2013-12-04 17:06:49 +00:00
|
|
|
|
|
|
|
// Test invalid deserializations
|
|
|
|
{
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
SkImageInfo info = SkImageInfo::MakeN32Premul(kBitmapSize, kBitmapSize);
|
2014-02-13 14:41:43 +00:00
|
|
|
|
2013-12-04 17:06:49 +00:00
|
|
|
SkBitmap validBitmap;
|
2014-02-13 14:41:43 +00:00
|
|
|
validBitmap.setConfig(info);
|
2013-12-04 17:06:49 +00:00
|
|
|
|
|
|
|
// Create a bitmap with a really large height
|
2014-02-13 14:41:43 +00:00
|
|
|
info.fHeight = 1000000000;
|
2013-12-04 17:06:49 +00:00
|
|
|
SkBitmap invalidBitmap;
|
2014-02-13 14:41:43 +00:00
|
|
|
invalidBitmap.setConfig(info);
|
2013-12-04 17:06:49 +00:00
|
|
|
|
|
|
|
// The deserialization should succeed, and the rendering shouldn't crash,
|
|
|
|
// even when the device fails to initialize, due to its size
|
|
|
|
TestBitmapSerialization(validBitmap, invalidBitmap, true, reporter);
|
|
|
|
}
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
|
|
|
|
// Test simple SkPicture serialization
|
|
|
|
{
|
2014-04-13 19:09:42 +00:00
|
|
|
SkPictureRecorder recorder;
|
2014-04-17 23:35:06 +00:00
|
|
|
bool didDraw = drawSomething(recorder.beginRecording(kBitmapSize, kBitmapSize, NULL, 0));
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
REPORTER_ASSERT(reporter, didDraw);
|
2014-04-13 19:09:42 +00:00
|
|
|
SkAutoTUnref<SkPicture> pict(recorder.endRecording());
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
|
|
|
|
// Serialize picture
|
|
|
|
SkWriteBuffer writer(SkWriteBuffer::kValidation_Flag);
|
|
|
|
pict->flatten(writer);
|
|
|
|
size_t size = writer.bytesWritten();
|
2014-03-14 21:22:22 +00:00
|
|
|
SkAutoTMalloc<unsigned char> data(size);
|
|
|
|
writer.writeToMemory(static_cast<void*>(data.get()));
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
|
|
|
|
// Deserialize picture
|
2014-03-14 21:22:22 +00:00
|
|
|
SkValidatingReadBuffer reader(static_cast<void*>(data.get()), size);
|
2014-03-13 16:18:49 +00:00
|
|
|
SkAutoTUnref<SkPicture> readPict(
|
|
|
|
SkPicture::CreateFromBuffer(reader));
|
|
|
|
REPORTER_ASSERT(reporter, NULL != readPict.get());
|
Fixing SkPicture serialization
Fixed a few issues while attempting to use the new
serialization path for SkPicture inside a fuzzer:
- SkReadBuffer and SkValidatingReadBuffer both had a fReader
member instead of sharing the same member, which leads to
problems if a base class function is used
- In SkPicture, a header is now written as a single chunk of
data, so it also has to be read as a single chunk of data
- In the SkPicturePlayback destructor, a bad deserialization
would lead to a crash if we don't safely unref fOpData
- Also in SkPicturePlayback, if we only use a ReadBuffer for
the whole deserialization, additional tags must be added to
parseBufferTag()
- SkValidatingReadBuffer::readBitmap() was broken, but this
path wasn't usen't since the only use case for
SkValidatingReadBuffer is currently image filters and
bitmaps are unflattened as part of the deserialization of
SkBitmapSource
- SkPictureImageFilter was not deserializable. Added it to
SkGlobalInitialization*
- Added a test that exercises the SkPicture serialization /
deserialization code
BUG=skia:
R=senorblanco@google.com, senorblanco@chromium.org, reed@google.com, robertphillips@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/195223003
git-svn-id: http://skia.googlecode.com/svn/trunk@13764 2bbb7eff-a529-9590-31e7-b0007b416f81
2014-03-12 14:46:41 +00:00
|
|
|
}
|
Adding size parameter to read array functions
In some cases, the allocated array into which the data will be read is using getArrayCount() to allocate itself, which should be safe, but some cases use fixed length arrays or compute the array size before reading, which could overflow if the stream is compromised.
To prevent that from happening, I added a check that will verify that the number of bytes to read will not exceed the capacity of the input buffer argument passed to all the read...Array() functions.
I chose to use the byte array for this initial version, so that "size" represents the same value across all read...Array() functions, but I could also use the element count, if it is preferred.
Note : readPointArray and writePointArray are unused, so I could also remove them
BUG=
R=reed@google.com, mtklein@google.com, senorblanco@chromium.org
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/37803002
git-svn-id: http://skia.googlecode.com/svn/trunk@12058 2bbb7eff-a529-9590-31e7-b0007b416f81
2013-10-31 18:37:50 +00:00
|
|
|
}
|