GNOME Bugzilla – Bug 737607
Exception swallowed while importing Gom
Last modified: 2017-01-03 04:36:30 UTC
Created attachment 287380 [details] test.js Using gom master and gjs master, the following small program fails to get the property value for the item we're trying to save in a database. $ sqlite3 /tmp/gom-js-test.db .dump PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE _gom_version (version INTEGER); INSERT INTO "_gom_version" VALUES(1); INSERT INTO "_gom_version" VALUES(2); CREATE TABLE 'items' ('id' INTEGER PRIMARY KEY AUTOINCREMENT,'url' TEXT); INSERT INTO "items" VALUES(1,NULL); DELETE FROM sqlite_sequence; INSERT INTO "sqlite_sequence" VALUES('items',1); COMMIT; A Gom.Resource object is created in Javascript, with the GObject properties handled in Javascript as well. When saving with Gom.Resource.save_sync(), gom sends the request to a worker thread, which will get the property from the object using g_object_get_property(). This will call into Javascript from a different thread. In gi/object.cpp, gjs_object_get_gproperty() the JS_GetProperty() call will fail.
Yep. JS is single-threaded. Too bad.
We could add assertions though of the form: g_assert (gjs_eval_thread == g_thread_self()); like object.cpp has. (Would need to hoist gjs_eval_thread to be hooked off the context).
(In reply to comment #1) > Yep. JS is single-threaded. Too bad. Fine. Give me errors telling me that :)
We did. We gave you an internal error. If you want more debugging information, then enable SpiderMonkey's debug mode, which has a lot of assertions related to this.
(In reply to comment #4) > We did. We gave you an internal error. It actually throws an error that never gets back to the caller. This is what you get at the end of the script: (gjs:26386): Gjs-WARNING **: EvaluateScript returned JS_TRUE but exception was pending; did somebody call gjs_throw() without returning JS_FALSE? (gjs:26386): Gjs-WARNING **: JS ERROR: InternalError: too much recursion That really doesn't look like the right error... > If you want more debugging information, then enable SpiderMonkey's debug mode, > which has a lot of assertions related to this. No, I want gjs to stop me doing stupid things, and to tell me which is that stupid thing.
Created attachment 342679 [details] [review] object: Make define_static_methods infallible Previously, gjs_object_define_static_methods() always returned true even if an exception was thrown, causing the exception to be swallowed. Since it never returned anything but true, we get rid of the return type. Exceptions thrown by fallible functions called within gjs_object_define_static_methods() are logged immediately and cleared. (Allowing the exceptions to propagate and be caught would potentially result in a GI namespace with only half its methods defined, and that seems undesirable.)
Bastien, here's what I get when I run your test script with the above patch: (gjs:28198): Gjs-WARNING **: JS ERROR: Error: Function Gom.set_property_from_bytes has a GDestroyNotify but no user_data, not supported @gom-test.js:14:5 (gjs:28198): Gjs-WARNING **: JS ERROR: Error: Function Gom.set_property_to_bytes has a GDestroyNotify but no user_data, not supported @gom-test.js:14:5 New item ID: 1 URL: http://www.gnome.org I don't see your original failure though. Perhaps the threading issue was solved elsewhere?
Worked-around, possibly: https://bugzilla.gnome.org/show_bug.cgi?id=728301
Review of attachment 342679 [details] [review]: Looks good to me.
I changed the title to match the actual issue that still needs solving.