ArrayBuffer::Allocator::Free() length differing from Allocate() length?

[Kenton Varda]

Hi v8-users,

We have an ArrayBufferAllocator implementation that counts how much memory has been allocated. It basically looks like this:

class AllocatorImpl final: public v8::ArrayBuffer::Allocator {

public:

  AllocatorImpl(): allocated(0) {}

  ~AllocatorImpl();

  inline size_t getMemoryUsage() const { return allocated; }

  void* Allocate(size_t length) {

    allocated += length;

    return calloc(length, 1);

  }

  void* AllocateUninitialized(size_t length) {

    allocated += length;

    return malloc(length);

  }

  void Free(void* data, size_t length) {

    allocated -= length;

    free(data);

  }

private:

  size_t allocated;

};

We're observing something strange: Sometimes (very rarely!), the `allocated` value drops below zero and wraps around, apparently indicating that V8 has Free()'d more than it Allocate()ed. However, there don't seem to be any issues with double-frees or freeing an invalid pointer.

Any idea what could lead to this? Is it possible for V8 to pass a different `legth` value to Free() than it passed to Allocate()?

Unfortunately I have no idea how to reproduce this reliably. It only happens very occasionally in production. :/

-Kenton

[Zac Hansen]

Have you compiled with ASAN?   Presumably if you're deleting more memory than you have, that would fire.  Just for debugging this, you could even put in a map of allocated addresses and sizes and just track what requests come in that don't seem to match.

It seems like requests that would cause this to go negative would end up sticking out like a sore thumb.

[eh...@chromium.org]

Are you using WebAssembly at all? What system are you running on?

WebAssembly has a mode on Linux x64 that uses signal handlers to do faster bounds checks. This requires V8 to reserve a much larger region of memory to use as guard regions, and sometimes we've made mistakes in accounting for this. If you're running into one of these issues, I'd be interested in debugging more. Note that the trap handler feature is off by default, so you probably aren't using this configuration unless you did something intentional to turn it on.

-Eric

On Wednesday, March 14, 2018 at 6:36:33 PM UTC-7, Kenton Varda wrote:

[Michael Lippautz]

Is that the exact implementation? v8::ArrayBuffer::Allocator is required to be thread-safe [1] as V8 potentially (depends on the platform implementation) offloads the freeing onto a different thread.

Cheers, -Michael

[1] https://cs.chromium.org/chromium/src/v8/include/v8.h?dr=CSs&l=4269

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.