How to use CefV8ArrayBuffer

[johnh]

I've tried a totally empty function now, same memory leak:

Code: Select all

PTAPI.GetImageData((imgdata: ArrayBuffer) => {
                    let pixelData = new Uint32Array(imgdata);
                    PTAPI.DestroyBuffer(imgdata);
                });


and

Code: Select all

PTAPI.GetImageData((imgdata: ArrayBuffer) => { PTAPI.DestroyBuffer(imgdata); });


So the leak is definitely coming from the native side.

[magreenblatt]

What is the native implementation of GetImageData?

[johnh]

I've traced this down to CreateArrayBuffer it seems..

Code: Select all

else if (list->GetType(0) == CefValueType::VTYPE_BINARY)
{
   int size = list->GetInt(1);
   CefRefPtr<CefBinaryValue> data = list->GetBinary(0);
   BYTE* pBuf = new (std::nothrow) BYTE[size];
   data->GetData(pBuf, size, 0);
   obj = CefV8Value::CreateArrayBuffer(pBuf, size, BrowserAPI::GetInstance());
   //delete[] pBuf;
}
arguments.push_back(obj);


1) Does CreateArrayBuffer take ownership of the buffer passed in or does it make it's own copy ?
If I don't delete pBuf the memory leak happens, but if I do delete it then CefV8ArrayBufferReleaseCallback crashes... it just looks like this:

Code: Select all


// Assuming ALL ArrayBuffers are created using new type[size]...
void BrowserAPI::ReleaseBuffer(void *buffer)
{
   delete[] buffer;
}



[magreenblatt]

It neither takes ownership of the buffer nor makes a copy. ReleaseBuffer should be called to free the buffer when the ArrayBuffer is GC'd, or when you call NeuterArrayBuffer. Is ReleaseBuffer being called for you?

[johnh]

Yes it's being called for a while initially.. then once I hit about 600mb usage it stops being called altogether...

EDIT: I can set a breakpoint on the delete[] and it fires continually at first, checking the buffer that it points at I can confirm it is the contents I'm expecting in the ArrayBuffer...
But it seems the calls just stop after a while.

[magreenblatt]

That sounds really odd. I don't know what would be causing that behavior.

[johnh]

I wonder if it might be related to the rate at which the calls happen, it's inside a RequestAnimationFrame .. so 60fps ..
Perhaps the buffers are being created faster than it can release them, doesn't explain why the GC would just stop.. but perhaps some sort of internal queue of items to be freed is jamming it up.. although I can't imagine that likely as tons of objects come in and out of scope during a normal RAF handler...

[johnh]

It's as if GC just gives , or at least whatever mechanism tries to call ReleaseBuffer..
The only other way around this would be to have a fixed ArrayBuffer which exists for the duration of the application and just update it's contents.. but that would require exposing V8 GetContents() to modify the data on the native side.

[johnh]

I'm using CEF 3.3440.1803

Do you think there would be any point trying to update to :

CEF 3.3440.1805?

If there might be anything in those 2 builds that might affect this.

[johnh]

tracing backwards I can tell you that this:

Code: Select all


void CEF_CALLBACK v8array_buffer_release_callback_release_buffer(
    struct _cef_v8array_buffer_release_callback_t* self,
    void* buffer) {
  // AUTO-GENERATED CONTENT - DELETE THIS COMMENT BEFORE MODIFYING

  DCHECK(self);
  if (!self)
    return;
  // Verify param: buffer; type: simple_byaddr
  DCHECK(buffer);
  if (!buffer)
    return;

  // Execute
  CefV8ArrayBufferReleaseCallbackCppToC::Get(self)->ReleaseBuffer(buffer);
}



Stops being called too.. so It would seem the problem is earlier in the chain, which seems to lead directly back into V8 itself ?