[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