GNOME Bugzilla – Bug 743049
Crashes on startup
Last modified: 2015-03-13 14:09:08 UTC
Searhorse at 3.14.0-37-ge413d0224f8712c0d52ee74e898b7d1fe9122711, running in Continuous VM crashes on startup. Traceback:
+ Trace 234560
Thread 4 (Thread 0x7fa750c74700 (LWP 1006))
Thread 3 (Thread 0x7fa751475700 (LWP 1005))
Thread 1 (Thread 0x7fa75dab5940 (LWP 975))
etc. etc., gdb showed it was 500+ frames
Still happens on 3.15.90-0-g0cc50b8d0b24fd239d570d1ea5ebf1ec1dfe9822, continuous build 20150226.42
#12 gck_object_cache_set_attributes at ../gck/gck-object-cache.c line 119 #13 object_set_property at ../../gobject/gobject.c line 1415 #14 g_object_set_valist at ../../gobject/gobject.c line 2159 #15 g_object_set at ../../gobject/gobject.c line 2269 #16 gck_object_cache_set_attributes at ../gck/gck-object-cache.c line 119 Looks like an infinite loop setting the object property, which sets the cached attribute, which sets the object property, etc. From the backtrace, this is a bug in gcr though.
seahorse/pkcs11/pkcs11-certificate.vala defines: public Gck.Attributes attributes { set { this._attributes = value; this.notify_property("attributes"); } } In 3.14, the generated C code was calling a seahorse_pkcs11_certificate_real_set_attributes() function which would do self->priv->_attributes = __vala_GckAttributes_copy0(value); In jhbuild, the generated C code is calling gcr_object_cache_set_attributes(pkcs11_certificate, value) which is doing g_object_set(self, "attributes", value, NULL). This will call againg GckAttributes::set_property(), which will call gcr_object_cache_set_attributes, ... causing this infinite loop. Looking in $prefix/share/vala/vapi/gck-1.vapi, the description of the GckObjectCache interface has: [ConcreteAccessor] public abstract Gck.Attributes attributes { owned get; set; } while in 3.14, it was [NoAccessorMethod] public abstract Gck.Attributes attributes { owned get; set; } Changing ConcreteAccessor to NoAccessorMethod and cleaning seahorse source tree then rebuilding it fixes the crash at startup. ConcreteAccessor was added in vala 0.27.1 release this January http://valajournal.blogspot.fr/ so this could be a vala bug, or a missing annotation in gcr so that vapigen does the right thing.
Ok thanks. With ConcreteAccessor we tried to keep up with the new pattern to have a C accessor in the interface which does g_object_get/set. Perhaps the solution is to not call the accessor within the set_property.
Both patterns can be found in the wild: - generic setter calls C setter - C setter calls g_object_set () The first one is more common, but both need to work.
Luca, will this be fixed on the vala side ?
Yes, it's a regression but will take some time before I start hacking on this.
In the meanwhile not sure if vala can be pinned to an older version, or gck adding an annotation to avoid ConcreteAccessor. Also still have to setup a proper environment for testing the changes.
what annotation would that be ?
Don't have gck at hand right now but a possibility would be to skip processing the accessor, something like: ObjectCache.set_attributes skip
Created attachment 299220 [details] [review] use real functions for ConcreteAccessor Ok I think this is easier than what I thought. Would you check if the attached patch solves the problem and everything works as expected? On a side note, g_object_notify is already done by vala, so you are doing it twice for your property.
Patch works for me (applied the patch, rebuilt seahorse after touching the .vala files, and it does not crash on startup).
commit 9b1a55a42082637c1559ca00bb46bb9ac739095d Author: Luca Bruno <lucabru@src.gnome.org> Date: Thu Mar 12 18:27:06 2015 +0100 codegen: use real function in set/get property also for ConcreteAccessor Fixes bug 743049 Let's see how it goes, thanks.