Preventing double-free error with `stablePtr`

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Preventing double-free error with `stablePtr`

Gershom Bazerman
I was just reading Roman Cheplyaka’s very interesting blog-post here: https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior.

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 (https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.html#v:withStablePtr)

Cheers,
Gershom

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

RE: Preventing double-free error with `stablePtr`

Haskell - Libraries mailing list

Catching double-frees does sound like a good idea to me.

 

Also, is the wisdom in Roman’s post captured in the StablePtr docs?  If not, can someone do that?

 

Simon

 

From: Libraries [mailto:[hidden email]] On Behalf Of Gershom B
Sent: 05 February 2018 01:38
To: Haskell Libraries <[hidden email]>
Subject: Preventing double-free error with `stablePtr`

 

I was just reading Roman Cheplyaka’s very interesting blog-post here: https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior.

 

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 (https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.html#v:withStablePtr)

 

Cheers,

Gershom


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Preventing double-free error with `stablePtr`

Carter Schonwald
would an alternative be to provide a helper that bundles a finalizer with the stable pointer and doens't allow explicit free on the associated stable pointer?

On Tue, Feb 6, 2018 at 4:11 AM, Simon Peyton Jones via Libraries <[hidden email]> wrote:

Catching double-frees does sound like a good idea to me.

 

Also, is the wisdom in Roman’s post captured in the StablePtr docs?  If not, can someone do that?

 

Simon

 

From: Libraries [mailto:[hidden email]] On Behalf Of Gershom B
Sent: 05 February 2018 01:38
To: Haskell Libraries <[hidden email]>
Subject: Preventing double-free error with `stablePtr`

 

I was just reading Roman Cheplyaka’s very interesting blog-post here: https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior.

 

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 (https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.html#v:withStablePtr)

 

Cheers,

Gershom


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Preventing double-free error with `stablePtr`

David Feuer
In reply to this post by Gershom Bazerman
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" <[hidden email]> wrote:
I was just reading Roman Cheplyaka’s very interesting blog-post here: https://ro-che.info/articles/2018-02-03-stableptr-undefined-behavior.

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 (https://hackage.haskell.org/package/Win32-2.6.2.0/docs/System-Win32-Types.html#v:withStablePtr)

Cheers,
Gershom

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries