I'm not sure if this was a change in Node >v0.10 or something that was always sneaking under the radar, but the story goes...
We use a config .yml file that enables resumable uploads to work without the user having to understand what's going on under the hood. (Documented here).
It looks like we're having a potentially huge leak here: https://github.com/GoogleCloudPlatform/gcloud-node/blob/61ffa82c78cce44ed28b94d8a857c7c051cae9d0/lib/storage/file.js#L1394
var firstChunk = chunk.slice(0, 16);
// ...
configStore.set(that.name, {
uri: reqOpts.uri,
firstChunk: firstChunk
});chunk is a Buffer. When you slice a buffer, it apparently keeps a property called parent, that is the entire original value of the buffer. As a result, we were writing the entire thing into a user's gcloud-node config file, when all we wanted was a measly 16kb.
Here's the fix:
var firstChunk = chunk.slice(0, 16).valueOf();
PR coming before today's release.
I'm not sure if this was a change in Node >v0.10 or something that was always sneaking under the radar, but the story goes...
We use a config .yml file that enables resumable uploads to work without the user having to understand what's going on under the hood. (Documented here).
It looks like we're having a potentially huge leak here: https://github.com/GoogleCloudPlatform/gcloud-node/blob/61ffa82c78cce44ed28b94d8a857c7c051cae9d0/lib/storage/file.js#L1394
chunkis a Buffer. When you slice a buffer, it apparently keeps a property calledparent, that is the entire original value of the buffer. As a result, we were writing the entire thing into a user's gcloud-node config file, when all we wanted was a measly 16kb.Here's the fix:
PR coming before today's release.