Preventing double-free error with `stablePtr`

David Feuer david.feuer at
Tue Feb 6 19:58:04 UTC 2018

Guaranteeing either idempotence or an error message seems to require that
the stable pointer (but not what it points to) remain allocated until there
are no more references to it. I don't know enough about these things to say
how hard or expensive that might be. Another possibility might be to avoid
reallocating a pointer too soon after it's freed; that would give a decent
chance at an error and might be less expensive.

On Feb 4, 2018 8:38 PM, "Gershom B" <gershomb at> wrote:

> I was just reading Roman Cheplyaka’s very interesting blog-post here:
> As he points out, the docs for `freeStablePtr` say
> "if the stable pointer is passed to deRefStablePtr or freeStablePtr, the
> behaviour is undefined.”
> And indeed we can observe weird behavior as a result of sucn an error.
> A deRef of a stable pointer is arguably the sort of sharp-edge we know how
> to code to avoid. But a double free is a bit trickier. Would it be worth
> adding a bit more overhead to make such an operation idempotent?
> Additionally, would it be worthwhile to add `withStablePtr` to the
> `Foreign.StablePtr` module? I imagine there are cases that it won’t cover,
> but it would at least encourage good discipline in the cases that it does
> handle. The evident utility of such a function is witnessed by its
> existence in a few different codebases, not least the Win32 library (
> System-Win32-Types.html#v:withStablePtr)
> Cheers,
> Gershom
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list