[bug] Use of Ruby's memory management causes crash in unrelated code that also uses libxml2 #2898
Labels
topic/memory
Segfaults, memory leaks, valgrind testing, etc.
Comments
mvz
added
the
state/needs-triage
|
@mvz Thanks for reporting this. I'll investigate. In the future, please fill out the template when reporting a bug, in particular the output from Error and stack trace from the 3.2 failing build: Error and stack trace from 3.3.0-preview1: |
flavorjones
added
topic/memory
|
OK, I've looked a bit and I think there are three independent contributing factors that are combining to cause this segfault. Three contributing factorsFirst, note that this isn't Nokogiri causing this problem, it's Second, something the glib2 gem is doing is allocating memory during Ruby's GC cycle. I'm not sure why this would be without some digging into the Third, Nokogiri is configuring it's version of libxml2 to use ruby's memory management functions which means that Recommended workaroundThese three things combine to cause this segfault. We can eliminate the segfault by removing any one (or more) of these three contributing factors. The third factor is the easiest to address -- you can set the environment variable to Longer-term fix for NokogiriThe first factor is something that I'm already planning to fix -- see #2746 which I'll probably update with a backreference to this issue. glib2 behaviorThe second factor is, ultimately, something up to the glib2 team to decide whether and how to address. It looks like the mark phase of GC is causing (maybe unintentionally) a whole bunch of work to happen. A cleaned up stack trace from the 3.3.0-preview1 stack dump shows this pretty clearly: |
|
Ah, I went to open an issue on The issue I was going to file looked like this, maybe you could file an upstream issue if you know what gem it is? g_object_get_property can end up doing a lot of work during the GC mark phase This is the stack trace of an error that was reported at #2898, which shows that the GC mark phase is triggering some significant computing that requires allocating new memory: I don't know glib or GTK very well anymore, but the issue seems to stem from calling static void
gobj_mark(gpointer ptr)
{
GObject* gobj = ptr;
guint n_properties;
GParamSpec** properties;
guint i;
properties = g_object_class_list_properties(G_OBJECT_GET_CLASS(gobj), &n_properties);
for (i = 0; i < n_properties; i++) {
GParamSpec* pspec = properties[i];
GType value_type = G_PARAM_SPEC_VALUE_TYPE(pspec);
if (G_TYPE_FUNDAMENTAL(value_type) != G_TYPE_OBJECT) continue;
if (!(pspec->flags & G_PARAM_READABLE)) continue;
/* FIXME: exclude types that doesn't have identity. */
{
GValue gval = G_VALUE_INIT;
g_value_init(&gval, value_type);
g_object_get_property(gobj, pspec->name, &gval);
rbgobj_gc_mark_gvalue(&gval);
g_value_unset(&gval);
}
}
g_free(properties);
}This seems like it's an unintentional side effect of some object's |
|
Thanks @flavorjones for the detailed analysis and explanation! Based on your three factors, I will
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Please describe the bug
This is a problem that occurs in CI when running the tests for alexandria. The test process crashes with Ruby 3.2 and up because libxml2 tries to allocate some memory during garbage collection and this is no longer allowed when using the Ruby allocator.
What I think happens is this:
In Ruby 3.3.0-preview1 the message is clearer due to ruby/ruby@a1758fb
Help us reproduce what you're seeing
See the build results for mvz/alexandria-book-collection-manager#236. I have not been able to reproduce this locally.
Expected behavior
Environment
Additional context
The text was updated successfully, but these errors were encountered: