Created attachment 67482 [details] [review]
proposed patch

That patch looks really useful. While resident modules of course hide
some bugs, I see no other way of properly valgrinding their memleaks
(as you said).

I have no objections to it, please go ahead.

What it needs though is to find the place in the api docs where we mention
the other DEBUG env vars, and add a note about G_MODULE_DEBUG

i think instead of G_MODULE_DEBUG, we can simply use G_DEBUG=resident-modules.
other than that, the patch looks good and makes sense to me.

Created attachment 70257 [details] [review]
updated patch

Reuse G_DEBUG env variable, and add documentation.

the patch looks mostly ok, allthough, we don't prefix "_g_" internal static variables in glib.
and, while we're at it, a second flag should be supported as well, "non-lazy-modules" which overrides G_MODULE_BIND_LAZY to cause modules to be loaded with BIND_NOW behaviour always.
allthough "bind-now-modules" would be an alternative non-negative flag name, i'm not sure it's really better, i'm open for suggestions.

Created attachment 72547 [details] [review]
updated patch

Implement bind-now-modules flag, and remove _g_ prefix.

(In reply to comment #6)
> the patch looks mostly ok, allthough, we don't prefix "_g_" internal static
> variables in glib.

Actually you do, or at least the debug code in glib/gmessages.c that I oriented myself at for this code does :)

> and, while we're at it, a second flag should be supported as well,
> "non-lazy-modules" which overrides G_MODULE_BIND_LAZY to cause modules to be
> loaded with BIND_NOW behaviour always.
> allthough "bind-now-modules" would be an alternative non-negative flag name,
> i'm not sure it's really better, i'm open for suggestions.

I like the positive name better.

I think bind-now-modules is better as it matches resident-modules, and
it also would cause less confusion if we decide we need lazy-modules
at some point.

thanks, applied.