[Issue 14934] GC interface doesn't allow safe extension of a memory range

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Wed Aug 19 07:20:25 PDT 2015


https://issues.dlang.org/show_bug.cgi?id=14934

Martin Nowak <code at dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code at dawg.eu
         Resolution|---                         |WORKSFORME

--- Comment #1 from Martin Nowak <code at dawg.eu> ---
And don't even think about what happens when a collection is triggered while
realloc copies the data from the old array to the new array.

> updateFunc would be called within the GC lock, preventing any of the issues described above.

Please let's try to avoid arbitrary code execution with the GC lock held.

> This would work if GC.disable would actually guarantee that the GC never runs. 

This is what
http://dlang.org/phobos/core_thread.html#.thread_enterCriticalRegion and
http://dlang.org/phobos/core_thread.html#.thread_exitCriticalRegion are for,
using them should readily solve your problem.

void* reallocImpl(void* p, size_t newSize)
{
  thread_enterCriticalRegion();
  auto oldp = p;
  p = realloc(p, newSize);
  if (p !is oldp)
  {
      GC.removeRange(oldp);
      GC.addRange(p, newSize);
  }
  thread_exitCriticalRegion();
  return newPtr;
}

--


More information about the Digitalmars-d-bugs mailing list