GNOME Bugzilla – Bug 792683
ephy-profile-migrator asserts on transition from 3.24.x to 3.26.x
Last modified: 2018-02-13 09:36:55 UTC
I'm building epiphany (and WebKit) with JHBuild (--buildtype=debugoptimized) With 3.26.5.1, on launching, I get: (ephy-profile-migrator:13527): GLib-CRITICAL **: the GVariant format string '(x&s&sdbas)' has a type of '(xssdbas)' but the given value has a type of '(xssxbas)' (ephy-profile-migrator:13527): GLib-CRITICAL **: g_variant_get: assertion 'valid_format_string (format_string, TRUE, value)' failed Failed to run the migrator process, Web will now abort. Also, with the same version but from Debian Testing (release build (?)), I get: (ephy-profile-migrator:15913): GLib-CRITICAL **: the GVariant format string '(x&s&sdbas)' has a type of '(xssdbas)' but the given value has a type of '(xssxbas)' (ephy-profile-migrator:15913): GLib-CRITICAL **: g_variant_get: assertion 'valid_format_string (format_string, TRUE, value)' failed (ephy-profile-migrator:15913): GLib-CRITICAL **: g_variant_new_string: assertion 'g_utf8_validate (string, -1, NULL)' failed (ephy-profile-migrator:15913): GLib-CRITICAL **: g_variant_iter_next_value: assertion 'is_valid_iter (iter)' failed (ephy-profile-migrator:15913): GLib-CRITICAL **: g_variant_iter_free: assertion 'is_valid_heap_iter (iter)' failed
I don't know if the criticals were already there by 3.24.x but, with 3.26.x is the first time it aborts at startup.
Can you please post a backtrace taken with G_DEBUG=fatal-criticals? We have been adding too many migrators recently... it would not be the first time that a change accidentally breaks an old migrator....
That code lives in convert_bookmark_timestamp() Reading that function, it looks like the variant was already migrated. Could be an aborted migration. Using g_variant_check_format_string() before g_variant_get() should be enough to avoid the error during migration.
Thanks Bastien! (In reply to Bastien Nocera from comment #3) > Using g_variant_check_format_string() before g_variant_get() should be > enough to avoid the error during migration. Interesting, I'd never have considered this....
Created attachment 367203 [details] BT from ephy-profile-migrator
(In reply to Michael Catanzaro from comment #2) > Can you please post a backtrace taken with G_DEBUG=fatal-criticals? > > We have been adding too many migrators recently... it would not be the first > time that a change accidentally breaks an old migrator.... This is a full BT from the abort, not with G_DEBUG=fatal-criticals "Unfortunately", I cannot reproduce any more. I don't know how it got solved ...
The following fix has been pushed: 3e26616 profile-migrator: Handle double bookmark timestamp migration
Created attachment 367236 [details] [review] profile-migrator: Handle double bookmark timestamp migration It's common for developers to run the profile migrator several times in a row. Migrators should be robust to this. We need to ensure the GVariant format is really the old format before using it in the timestamp migration.
The following fix has been pushed: 5a8870f profile-migrator: Fix format string check added in previous commit
Created attachment 367242 [details] [review] profile-migrator: Fix format string check added in previous commit
(In reply to Andres Gomez from comment #6) ... > "Unfortunately", I cannot reproduce any more. I don't know how it got solved > ... But not without price, it seems I lost my bookmarks in the process :(
(In reply to Andres Gomez from comment #11) > But not without price, it seems I lost my bookmarks in the process :( That's probably a direct consequence of this bug... a table of zero bookmarks would have been written to the bookmarks file. Sorry. :/ My patch ensures the bookmarks file is no longer written to at all in this case.
Created attachment 368238 [details] New BT from ephy-profile-migrator This doesn't seem to be completely solved. I've now opened an instance of a web app that I had not used in some time. Ephy is 3.26.5.1 with the previous patch applied. It SIGSEVed too.
Can you rebuild with -g for a better backtrace? The one you have there is not actionable.
(In reply to Andres Gomez from comment #13) > This doesn't seem to be completely solved. Bastien, I was going to do 3.26.6 today (really!), but I think I will delay one more day because of this.
(In reply to Michael Catanzaro from comment #14) > Can you rebuild with -g for a better backtrace? The one you have there is > not actionable. Ouch! Checking my config this is not coming from where I claimed it was. Closing again. Thanks!