After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630179 - modules do not support unloading
modules do not support unloading
Status: RESOLVED DUPLICATE of bug 622896
Product: gjs
Classification: Bindings
Component: general
Other Linux
: Normal normal
: ---
Assigned To: gjs-maint
Depends on:
Reported: 2010-09-20 15:48 UTC by Colin Walters
Modified: 2010-09-23 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Colin Walters 2010-09-20 15:48:40 UTC
While porting to XULRunner 1.9.3, the debugger test hangs.  Leaving aside the levels of crazy in exposing setDebugErrorHook to JavaScript, the core problem here is that it has static C variables, which in turn hold references to JS Objects.

The static C is problematic enough; but the fact that we hold JS objects means that the GC will simply loop forever trying to collect.  (It's required that we drop all JS object references before calling JS_DestroyContext).

Proposed solution: change the module API to:

1) Take GjsContext, not JSContext *
2) Add an "unload" hook
Comment 1 Havoc Pennington 2010-09-20 16:10:29 UTC
In this particular case, see gi/closure.c ; I think the GClosure should be getting a dnotify from the context already and dropping its JS object references as a result...  so maybe that is more generally broken.

Re: 1), Spreading GjsContext around more gives me some pause since I think GjsContext is a little hosed (conflating context and runtime), and becomes more so with the new compartments stuff... but, this is more of a vague worry than anything concrete.
Comment 2 Colin Walters 2010-09-23 14:47:19 UTC
This one is actually just a dup of the nested context -> confusing request count -> infinitely blocking GC

*** This bug has been marked as a duplicate of bug 622896 ***