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 742574 - Calling JSContextRef related functions from Java finalizers
Calling JSContextRef related functions from Java finalizers
Status: RESOLVED FIXED
Product: seed
Classification: Bindings
Component: libseed
git master
Other Linux
: Normal critical
: ---
Assigned To: seed-maint
seed-maint
Depends on:
Blocks:
 
 
Reported: 2015-01-08 09:26 UTC by Sebastian Dröge (slomo)
Modified: 2015-01-08 09:56 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
closure: Don't call JSValueUnprotect() from a finalizer (1.17 KB, patch)
2015-01-08 09:27 UTC, Sebastian Dröge (slomo)
none Details | Review
engine: Don't call JSValueUnprotect() from the finalizer of the object (2.37 KB, patch)
2015-01-08 09:27 UTC, Sebastian Dröge (slomo)
none Details | Review

Description Sebastian Dröge (slomo) 2015-01-08 09:26:21 UTC
It's not allowed to call JSContextRef related functions from Java finalizers, or anything that can cause GC for that matter:
http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/API/JSObjectRef.h#L94

Attached patches fix the two occurences of this, which would cause crashes otherwise.
Comment 1 Sebastian Dröge (slomo) 2015-01-08 09:27:21 UTC
Created attachment 294075 [details] [review]
closure: Don't call JSValueUnprotect() from a finalizer

We would not get here at all anyway if the object still had a "protect count"
higher than 0, as that would prevent the GC from cleaning up the object.

Also the docs say:

You must not call any function that may cause a garbage collection or an allocation
of a garbage collected object from within a JSObjectFinalizeCallback. This includes
all functions that have a JSContextRef parameter.
Comment 2 Sebastian Dröge (slomo) 2015-01-08 09:27:25 UTC
Created attachment 294076 [details] [review]
engine: Don't call JSValueUnprotect() from the finalizer of the object

JSValueUnprotect() would be called from g_object_set_data_full() via the
destroy notify we set for the data before. Steal the qdata instead as this
won't call the destroy notify, and we don't have to clean up anything here.

We would not get here at all anyway if the object still had a "protect count"
higher than 0, as that would prevent the GC from cleaning up the object.

Also the docs say:

You must not call any function that may cause a garbage collection or an allocation
of a garbage collected object from within a JSObjectFinalizeCallback. This includes
all functions that have a JSContextRef parameter.

Also consistently use the qdata variants of the functions instead of the data
variants that take a string instead of a quark.
Comment 3 Alan Knowles 2015-01-08 09:56:03 UTC
Thanks - I'd been removing the unprotect locally for a while, but never quite sure if it was just me...

All committed.