Memory leaks are a pain for gem users. They are hard to track and can lead to expensive infrastructure costs.
Memory leaks within a C extension are even worse. You'll see a lot of tools and articles about finding leaks in Ruby. However, you don't have the same access to internals in C.
A naive usage of rb_funcall
can cause memory leaks: it's much better to use rb_protect
instead. So, if you are a C extension
writer, please read on for the sake of developers who will use your gem.
Let's get started!
The Issue with rb_funcall
and C
rb_funcall
can be a great tool when you need to interact between Ruby and the C parts
of your library but only need to write a little C.
However, when you run rb_funcall
, you are no longer in C where everything is
straightforward. You can be left in muddy waters if the called function:
- Completely changes its definition during runtime
- Raises a call
Number 1 is the easiest one to catch. You'll likely end up with a segfault, and if your test suite is complete enough, you should catch that before publishing.
However, the latter can cause memory leaks and make your codebase way harder to read. Let's take a look at that now.
Raise in Ruby Causing C Memory Leaks
Ruby's raising mechanism jumps between parts of the code from one scope to the
first parent that catches an error. This is implemented in the MRI using longjmp
and setjmp
.
If you are interested in how this is built, read the
Evaluator chapter in the Ruby Hacking Guide. In a nutshell, when
you use a begin..ensure
block, you setjmp()
, and when you raise within
this block, you longjmp()
to the saved position.
So if a function is raised with rb_funcall
, the C code called after it
never executes.
The example below illustrates a potential leak. If json_parse
raises, it will
leak.
Of course, the example above is a bit silly — you could invert the freeing and Ruby processing parts. However, this is not always possible, and longer function bodies can become more intertwined.
Using begin..ensure
in Ruby
If you're using Ruby, you could instead write the above example using
begin..ensure
:
This API is also available in C with rb_rescue
and rb_ensure
:
However, this is a bit cumbersome, and if you want to add a rescue
block to
the party, it gets way less readable. I suggest reading Peter Zhu's 'A Rubyist's Walk Along the C-side (Part 8): Exceptions & Error Handling'
if you want to use the begin..rescue..ensure..end
API in C.
Using rb_protect
for C
There is another option. First, let's see how it could look in Ruby:
This looks strange in Ruby, but is a workflow very well
suited to C. The MRI has an API for that, rb_protect
, and the C function looks like this:
The above method will re-raise a Ruby error after having freed everything.
Note that we could also choose to ignore the error by using an
empty rescue
block in Ruby:
Warning: If you do not raise the error, the rb_set_errinfo(Qnil)
step is
important so you don't keep information available about an error that users should not know
about.
Or, you can conditionally choose to raise an error, like rescue My::Error
:
You can actually consider rb_errinfo()
as the same as the $!
global
variable.
This is all great, but when it boils down to one rb_funcall
only, we can simplify that API.
The overall idea behind using the rb_protect
API when there is a function
to raise is to enhance readability. You don't need to check if the
function can raise or not, you assume it can, and use the state to work with
that.
The rb_protect_funcall
Proposal
Let's isolate rb_funcall
, as it's the only dangerous method to use. Here's an API that will do that:
This API is the same as rb_funcall
, with a state
from rb_protect
. Hence the
usage is pretty straightforward:
This API is not yet available in Ruby, and may never be. You can take it from RGeo (MIT LICENSE).
A Real-World Example
If you want to see a real-world example, I encourage you to read the RGeo
codebase as we recently switched to going full rb_protect
. We even
have some functions, such as rgeo_convert_to_geos_geometry
, that propagate
this state for simpler usage. This function is a good place to start digging
around.
Feel free to open an issue on RGeo to discuss the choices we made further.
Wrapping Up
In this post, we warned against using rb_funcall
with C as it can cause memory leaks. We explored using begin..ensure
or rb_protect
instead.
Happy coding!
P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!