Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More glib errors when updating appstream cache #141

Closed
antonio-rojas opened this issue Sep 30, 2017 · 15 comments
Closed

More glib errors when updating appstream cache #141

antonio-rojas opened this issue Sep 30, 2017 · 15 comments

Comments

@antonio-rojas
Copy link
Contributor

When updating the appstream cache with the metadata generated by asgen 0.6.6 and appstrem 0.11.5, we're getting errors:

(2/2) Updating the appstream cache...

(appstreamcli:13559): GLib-CRITICAL **: g_variant_builder_end: assertion '!GVSB(builder)->uniform_item_types || GVSB(builder)->prev_item_type != NULL || g_variant_type_is_definite (GVSB(builder)->type)' failed

(appstreamcli:13559): GLib-CRITICAL **: g_variant_new_variant: assertion 'value != NULL' failed

(appstreamcli:13559): GLib-ERROR **: g_variant_new_parsed: 11-13:invalid GVariant format string
error: command terminated by signal 5: Trace/breakpoint trap
@ximion
Copy link
Owner

ximion commented Sep 30, 2017

Can you maybe generate a backtrace for this? (Install debuginfo, set a breakpoint on g_error)

@antonio-rojas
Copy link
Contributor Author

antonio-rojas commented Sep 30, 2017

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff78ce512 in ?? () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0x00007ffff78ce512 in  () at /usr/lib/libglib-2.0.so.0
#1  0x00007ffff78cf5bd in g_log_default_handler () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff78cf85f in g_logv () at /usr/lib/libglib-2.0.so.0
#3  0x00007ffff78cf9e0 in g_log () at /usr/lib/libglib-2.0.so.0
#4  0x00007ffff7909984 in g_variant_new_parsed_va () at /usr/lib/libglib-2.0.so.0
#5  0x00007ffff7909b3c in g_variant_builder_add_parsed () at /usr/lib/libglib-2.0.so.0
#6  0x00007ffff7bbb4ab in as_screenshot_to_variant (screenshot=0x5555572d29c0, builder=builder@entry=0x7fffffffe090)
    at ../AppStream-0.11.5/src/as-screenshot.c:587
#7  0x00007ffff7bb3feb in as_component_to_variant (cpt=cpt@entry=0x5555572cd5c0, builder=builder@entry=0x555555784720)
    at ../AppStream-0.11.5/src/as-component.c:4993
#8  0x00007ffff7bb8e37 in as_cache_file_save (fname=fname@entry=0x555555783030 "/var/cache/app-info/gv/es_ES.gvz", locale=0x5555557831a0 "es_ES", cpts=cpts@entry=0x555557419f40, error=error@entry=0x7fffffffe210) at ../AppStream-0.11.5/src/as-pool.c:1616
#9  0x00007ffff7bb9166 in as_pool_save_cache_file (pool=pool@entry=0x5555557840d0, fname=fname@entry=0x555555783030 "/var/cache/app-info/gv/es_ES.gvz", error=error@entry=0x7fffffffe210) at ../AppStream-0.11.5/src/as-pool.c:1086
#10 0x00007ffff7bb935c in as_pool_refresh_cache (pool=pool@entry=0x5555557840d0, force=force@entry=0, error=error@entry=0x7fffffffe250)
    at ../AppStream-0.11.5/src/as-pool.c:1529
#11 0x000055555555a247 in ascli_refresh_cache (cachepath=0x0, datapath=0x0, forced=0) at ../AppStream-0.11.5/tools/ascli-actions-mdata.c:60
#12 0x0000555555557fc1 in as_client_run_refresh_cache (argc=<optimized out>, argv=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:237
#13 0x0000555555557fc1 in as_client_run (argv=<optimized out>, argc=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:690
#14 0x00007ffff6eccf6a in __libc_start_main () at /usr/lib/libc.so.6
#15 0x00005555555574da in _start ()

ximion added a commit that referenced this issue Sep 30, 2017
@ximion
Copy link
Owner

ximion commented Sep 30, 2017

Can you check if the patch above changes anything? I am just guessing here, but I think you might have an empty <screenshot/> tag somewhere, or the pool tries to cache an old <screenshot>url</screenshot> tag, in which case I should make this more robust. (From looking at things, the validator should also warn about these invalid screenshot tags).

@antonio-rojas
Copy link
Contributor Author

The patch fixes the GLib-ERROR and the second GLib-CRITICAL. Still getting lots of the first GLib-CRITICAL though

@ximion
Copy link
Owner

ximion commented Sep 30, 2017

Can you set a breakpoint on g_critical (or g_log if that fails) and give me another backtrace? From the errors it's hard to guess what went wrong.

@antonio-rojas
Copy link
Contributor Author

With g_critical it doesn't break. With g_log:

Breakpoint 2, 0x00007ffff78cf950 in g_log () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0x00007ffff78cf950 in g_log () at /usr/lib/libglib-2.0.so.0
#1  0x00007ffff7bb604f in as_pool_add_metadata_location_internal (pool=<optimized out>, directory=0x7ffff7bc5824 "/usr/share/app-info", add_root=0)
    at ../AppStream-0.11.5/src/as-pool.c:1834
#2  0x00007ffff7bb6314 in as_pool_init (pool=0x5555557838d0) at ../AppStream-0.11.5/src/as-pool.c:193
#3  0x00007ffff7658b9d in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0
#4  0x00007ffff7638939 in  () at /usr/lib/libgobject-2.0.so.0
#5  0x00007ffff763a15d in g_object_new_with_properties () at /usr/lib/libgobject-2.0.so.0
#6  0x00007ffff763ac12 in g_object_new () at /usr/lib/libgobject-2.0.so.0
#7  0x00007ffff7bb9484 in as_pool_new () at ../AppStream-0.11.5/src/as-pool.c:1990
#8  0x000055555555a121 in ascli_refresh_cache (cachepath=0x0, datapath=0x0, forced=1) at ../AppStream-0.11.5/tools/ascli-actions-mdata.c:41
#9  0x0000555555557fc1 in as_client_run_refresh_cache (argc=<optimized out>, argv=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:237
#10 0x0000555555557fc1 in as_client_run (argv=<optimized out>, argc=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:690
#11 0x00007ffff6eccf6a in __libc_start_main () at /usr/lib/libc.so.6
#12 0x00005555555574da in _start ()

You can find the xmls that trigger this on https://sources.archlinux.org/other/packages/archlinux-appstream-data/20170929/

@ximion
Copy link
Owner

ximion commented Sep 30, 2017

Yeah, it breaks on a debug statement now (you'd need to forward until you hit the critical warning). I will test with your XML later tonight, that's probably the easiest way to debug this (and also makes writing a unittest easier).

@antonio-rojas
Copy link
Contributor Author

Another try...

Breakpoint 1, 0x00007ffff78cf950 in g_log () from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0x00007ffff78cf950 in g_log () at /usr/lib/libglib-2.0.so.0
#1  0x00007ffff79022dd in g_variant_builder_end () at /usr/lib/libglib-2.0.so.0
#2  0x00007ffff7bb4001 in as_component_to_variant (cpt=cpt@entry=0x5555575959d0, builder=builder@entry=0x555555784720)
    at ../AppStream-0.11.5/src/as-component.c:4996
#3  0x00007ffff7bb8e37 in as_cache_file_save (fname=fname@entry=0x555555783080 "/var/cache/app-info/gv/es_ES.gvz", locale=0x5555557831d0 "es_ES", cpts=cpts@entry=0x5555574a7a40, error=error@entry=0x7fffffffe200) at ../AppStream-0.11.5/src/as-pool.c:1616
#4  0x00007ffff7bb9166 in as_pool_save_cache_file (pool=pool@entry=0x5555557840d0, fname=fname@entry=0x555555783080 "/var/cache/app-info/gv/es_ES.gvz", error=error@entry=0x7fffffffe200) at ../AppStream-0.11.5/src/as-pool.c:1086
#5  0x00007ffff7bb935c in as_pool_refresh_cache (pool=pool@entry=0x5555557840d0, force=force@entry=1, error=error@entry=0x7fffffffe240)
    at ../AppStream-0.11.5/src/as-pool.c:1529
#6  0x000055555555a247 in ascli_refresh_cache (cachepath=0x0, datapath=0x0, forced=1) at ../AppStream-0.11.5/tools/ascli-actions-mdata.c:60
#7  0x0000555555557fc1 in as_client_run_refresh_cache (argc=<optimized out>, argv=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:237
#8  0x0000555555557fc1 in as_client_run (argv=<optimized out>, argc=<optimized out>) at ../AppStream-0.11.5/tools/appstream-cli.c:690
#9  0x00007ffff6eccf6a in __libc_start_main () at /usr/lib/libc.so.6
#10 0x00005555555574da in _start ()

@ximion
Copy link
Owner

ximion commented Sep 30, 2017

@antonio-rojas That does it, thanks! I did not anticipate GVariantBuilder being annoyed by trying to add an empty array or other type.
It's documented though:

It is also an error to call this function if the builder was created with an indefinite array or maybe type and no children have been added; in this case it is impossible to infer the type of the empty array.

This only ever happens for broken or incomplete metadata, which happens to be the case here (and the pre-validation wasn't as excessive for screenshots as it is for other types).
Fortunately, this is easy to fix.

@ximion ximion closed this as completed in 376d314 Oct 1, 2017
@ximion
Copy link
Owner

ximion commented Oct 1, 2017

@antonio-rojas Okay, this should be fixed now. But there are a few other changes I want to do to catch these issues earlier (this should not even hit the cache).
Are the hint HTML pages for the components available somewhere? I would like to check why some screenshot entries are empty in the first place.

The things on the todo list now are to make the validator more strict about screenshot tags and to make the generator not output useless screenshot entries.

@antonio-rojas
Copy link
Contributor Author

Here it is:
http://pkgbuild.com/~arojas/appstream/

Any plans for a release soon with the latest fixes?

@ximion
Copy link
Owner

ximion commented Oct 1, 2017

I'll do a release of both asgen and AppStream as soon as I have made the changes mentioned here :-) (so, likely next week)

@ximion
Copy link
Owner

ximion commented Oct 1, 2017

@antonio-rojas Did you disable metadata validation in your asgen run?

@antonio-rojas
Copy link
Contributor Author

Yes. I don't remember the reason TBH, but I've had it disabled for a long time.

@ximion
Copy link
Owner

ximion commented Oct 1, 2017

@antonio-rojas Ah, that cofused me a lot here, because I thought there was something wrong with the generator not producing any warnings for this ^^
So, it looks like that part is fine afterall, and this issue was just caused by missing support for legacy AppStream files after I refactored the XML parser a few releases ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants