Refresh hangs #35

neilmayhew · 2016-05-02T22:32:20Z

I have a third-party Ubuntu repo at http://packages.sil.org/ubuntu. I'm using a Xenial test machine. After refreshing sources with apt-get update, I run appstreamcli as follows:

sudo tools/appstreamcli refresh --force --verbose --details

It then hangs, using 100% CPU. I've left it as long as 10 minutes and it still doesn't finish. The output is:

** (appstreamcli:13992): DEBUG: Refreshing AppStream cache
** (appstreamcli:13992): DEBUG: Reading: /usr/share/app-info/xmls/org.freedesktop.fwupd.xml
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial_main_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_main_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_restricted_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_universe_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_multiverse_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_main_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_restricted_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_universe_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_multiverse_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/packages.sil.org_ubuntu_dists_xenial_main_dep11_Components-amd64.yml.gz
** (appstreamcli:13992): DEBUG: Reading: /var/lib/app-info/yaml/packages.sil.org_ubuntu_dists_xenial_universe_dep11_Components-amd64.yml.gz

If I run it from a root shell (sudo -s) or wrap it with a shell (sudo bash -c '...') I get the same result. Previously, it would run successfully like this, but the behaviour has now changed. The only difference I can think of is that I've installed build dependencies for appstream and have built it from source. However, I haven't done make install and it doesn't matter whether I run the built-from-source version or the installed package.

Very annoyingly, if I try to run appstreamcli from gdb, it runs successfully! So I can't step through the code and see exactly what's happening. Instead, I'm having to rely on creating a core dump, and because it's being run from a set-uid program, I have to set /proc/sys/fs/suid_dumpable and /proc/sys/kernel/core_pattern appropriately. I can then use ^\ to send SIGQUIT and use gdb on the resulting core dump.

I get the following backtrace:

#0  0x00007f912e1a18b4 in yaml_event_delete () from /usr/lib/x86_64-linux-gnu/libyaml-0.so.2
#1  0x00007f912fa767e0 in as_yamldata_parse_distro_data (ydt=0x1612d20, 
    data=0x1712580 "---\nFile: DEP-11\nVersion: '0.8'\nOrigin: pso-ubuntu-xenial-universe\nMediaBaseUrl: http://packages.sil.org/ubuntu/appstream/media\n\360\273p\001", error=0x7ffff1342c20) at /home/mayhewn/src/appstream/appstream/src/as-yamldata.c:1932
#2  0x00007f912fa77063 in as_metadata_parse_yaml (metad=0x161ed40, 
    data=0x1712580 "---\nFile: DEP-11\nVersion: '0.8'\nOrigin: pso-ubuntu-xenial-universe\nMediaBaseUrl: http://packages.sil.org/ubuntu/appstream/media\n\360\273p\001", error=0x7ffff1342c20) at /home/mayhewn/src/appstream/appstream/src/as-metadata.c:255
#3  0x00007f912fa77486 in as_metadata_parse_file (metad=0x161ed40, file=0x1619d40, error=0x7ffff1342c20)
    at /home/mayhewn/src/appstream/appstream/src/as-metadata.c:357
#4  0x00007f912fa7cc2b in as_data_pool_load_metadata (dpool=0x1612c80) at /home/mayhewn/src/appstream/appstream/src/as-data-pool.c:465
#5  0x00007f912fa7ce29 in as_data_pool_update (dpool=0x1612c80, error=0x7ffff1342d00)
    at /home/mayhewn/src/appstream/appstream/src/as-data-pool.c:512
#6  0x00007f912fa6c76b in as_cache_builder_refresh (builder=0x1612c30, force=0, error=0x7ffff1342d78)
    at /home/mayhewn/src/appstream/appstream/src/as-cache-builder.c:537
#7  0x0000000000405114 in ascli_refresh_cache (dbpath=0x0, datapath=0x0, forced=0)
    at /home/mayhewn/src/appstream/appstream/tools/ascli-actions-mdata.c:61
#8  0x0000000000403d61 in as_client_run (argv=0x7ffff1343128, argc=2) at /home/mayhewn/src/appstream/appstream/tools/appstream-cli.c:202
#9  0x000000000040405b in main (argc=4, argv=0x7ffff1343128) at /home/mayhewn/src/appstream/appstream/tools/appstream-cli.c:255

The content of /var/lib/app-info/yaml/packages.sil.org_ubuntu_dists_xenial_universe_dep11_Components-amd64.yml.gz is:

---
File: DEP-11
Version: '0.8'
Origin: pso-ubuntu-xenial-universe
MediaBaseUrl: http://packages.sil.org/ubuntu/appstream/media

It looks like as_metadata_parse_yaml is being given some extra junk characters on the end of the real data (\360\273p\001). These are definitely not in the real file (I checked with zcat ... | hexdump -C).

The output of ldd tools/appstreamcli is:

    linux-vdso.so.1 =>  (0x00007ffe1313f000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f0869571000)
    libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007f08691e8000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f0868f95000)
    libappstream.so.3 => /home/mayhewn/src/appstream/appstream/build/src/libappstream.so.3 (0x00007f0868d22000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0868958000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f08686e8000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f08684cb000)
    libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f08682c6000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f08680ac000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f0867e8a000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0867c6e000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f0867a66000)
    libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f08676ac000)
    libyaml-0.so.2 => /usr/lib/x86_64-linux-gnu/libyaml-0.so.2 (0x00007f086748c000)
    libxapian.so.22 => /usr/lib/x86_64-linux-gnu/libxapian.so.22 (0x00007f0867090000)
    libprotobuf-lite.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf-lite.so.9 (0x00007f0866e5f000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0866adc000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f08668c6000)
    /lib64/ld-linux-x86-64.so.2 (0x00005635c4a6a000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f08666c2000)
    libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f086632d000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f086610b000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0865e02000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f0865bfc000)
    libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f0864145000)

So it's picking up system libraries for everything except libappstream.so.3, as it should.

The text was updated successfully, but these errors were encountered:

neilmayhew · 2016-05-02T22:44:14Z

It looks to me like g_memory_output_stream_get_data on line 324 is giving back the data without a terminating '\0', and it's then being interpreted as a C-string by g_strdup on the next line. As a result, it picks up whatever garbage happens to follow the result of g_memory_output_stream_get_data in memory.

You probably just need to add a g_output_stream_write(mem_os, "", 1, NULL, NULL).

neilmayhew · 2016-05-02T22:47:23Z

Yes, that fixes it. I'll submit a PR.

ximion · 2016-05-02T23:22:04Z

Yes, looks good!
I need to do some benchmarks again to see if firing up the full YAML parser is really that much slower so that it justifies the hack in there at all...
But meanwhile, g_strndup is the way to go :)

neilmayhew · 2016-05-06T23:58:57Z

Is there any chance of getting this into Xenial as an SRU? It's hanging my stock Xenial machine all the time ATM. I assume my g_strndup patch could go into the package since it's a minimal change that fixes the bug. Should I create a LP issue or do you want to do that?

ximion · 2016-05-07T00:01:01Z

Do you have a way to reproduce this? That would help getting a SRU done. In any case, you reporting a bug would be helpful, I could take it from there then.

neilmayhew · 2016-05-07T03:15:06Z

I could bundle up the files that refresh uses. The verbose output shows it using /var/lib/app-info/ which in turn contains symlinks to /var/lib/apt/lists. I don't know if it would be 100% reproducible even then, since it's a result of reading uninitialized memory, but if you too could reproduce it when using those files then the behaviour is probably consistent.

Are there any other directories I'd need to include?

ximion · 2016-05-07T04:32:55Z

Hmm, including the files likely doesn't make sense, since every Ubuntu user has the exact same data in those directories.
I was asking for reproducibility because I am actually quite puzzled that this major bug was in the code for years since libappstream was translated from Vala to C, without me or anyone else experiencing the issue - which makes absolutely no sense, because even if the memory allocation for the new string terminated quickly at a null byte, the following XML and YAML parsing step would have complained about the garbage data.
So, at time I think the compiler might have done something to make this bug happen less often, or some other condition was in effect which shadowed the bug for years - I still can't reproduce it today. At least, this is not a security issue, in this case... Phew.
Anyway, it's good that you found it which triggered me to finally rewrite that super-old and badly-translated-from-Vala code in a sane way.

neilmayhew · 2016-05-07T05:01:17Z

including the files likely doesn't make sense, since every Ubuntu user has the exact same data in those directories.

They don't have the data from my third-party repo, although I know you've tried it with my repo configured. Perhaps it's just some unlikely data-ordering thing that triggers it. I assume the files are read in the order that they happen to be stored in the directory, and not alphabetical order, so even with the same files the problem might not occur. I'll see if I can get it to occur on a different machine.

neilmayhew · 2016-05-10T13:12:09Z

I can reproduce it 100% in a very simple docker container. Here's the Dockerfile:

FROM ubuntu:xenial

RUN export DEBIAN_FRONTEND=noninteractive \
 && apt-get update \
 && apt-get dist-upgrade -y \
 && apt-get install -y --no-install-recommends \
    appstream

To use it, put this text in a file called Dockerfile in a directory on its own somewhere, and cd to that directory.

Build the container with:

docker build -t appstream .

Run the container with:

docker run --rm -it appstream

Once in the container:

apt-get update

It fetches the indices, including DEP-11, and then hangs. Running top on the host shows that appstreamcli is using 100% CPU. It runs forever, until terminated with Ctrl-C.

Note: I'm using overlayfs as my Docker storage backend, but I've been able to reproduce this on multiple machines without using Docker, so I don't think it's related to the use of overlayfs.

If I take --no-install-recommends out of the apt-get install I get different behaviour. This time, the appstreamcli run by apt-get update terminates with an error:

** (appstreamcli:256): CRITICAL **: Error while moving old database out of the way.
AppStream cache update failed.

Running appstreamcli refresh --force --verbose --details manually doesn't give any more useful information:

...
** (appstreamcli:262): DEBUG: zathura-pdf-poppler.desktop extends zathura.desktop, but zathura.desktop was not found.
** (appstreamcli:262): DEBUG: Removing old rebuild-dir from previous database rebuild.
** (appstreamcli:262): CRITICAL **: Error while moving old database out of the way.
AppStream cache update failed.

I assume that having the recommended dependencies present just changes the layout in memory enough to produce different random behaviour.

ximion · 2016-05-10T16:21:56Z

CRITICAL **: Error while moving old database out of the way. AppStream cache update failed.

This indicates that the tool couldn't write to /var/cache/app-info/xapian, which shoukd never happen. This is probably an issue with docker, instead of having anything to do with this issue.
Anyway, a fix for this issue has been uploaded to xenial-proposed, so we need to wait for it to get accepted.

neilmayhew · 2016-05-10T17:11:57Z

Two things:

How can I help this along in the acceptance process? (eg by filing a bug on LP)
I'm concerned that the fixes we've created don't actually fix the bug, just shift it around so we don't see it in the test scenario any more. I find it very odd that installing recommends causes the behaviour to change so significantly. Also that a few garbage bytes on the end of the YAML data would cause the YAML parsing to go into an infinite loop. Something doesn't quite add up here.

I used Ctrl-\ in the docker container to produce a core dump, and then using gdb to get a backtrace I get almost the same stack as before:

#0  0x00007ff7ed6c98b4 in yaml_event_delete () from /usr/lib/x86_64-linux-gnu/libyaml-0.so.2
#1  0x00007ff7eef83c62 in as_yamldata_parse_distro_data () from /usr/lib/x86_64-linux-gnu/libappstream.so.3
#2  0x00007ff7eef85537 in as_metadata_parse_yaml () from /usr/lib/x86_64-linux-gnu/libappstream.so.3
#3  0x00007ff7eef85c55 in as_metadata_parse_file () from /usr/lib/x86_64-linux-gnu/libappstream.so.3
#4  0x00007ff7eef88d49 in as_data_pool_update () from /usr/lib/x86_64-linux-gnu/libappstream.so.3
#5  0x00007ff7eef7e272 in as_cache_builder_refresh () from /usr/lib/x86_64-linux-gnu/libappstream.so.3
#6  0x00000000004049de in ascli_refresh_cache ()
#7  0x0000000000403ceb in as_client_run ()
#8  0x00007ff7eebac830 in __libc_start_main (main=0x403490 <main>, argc=3, argv=0x7fff93803fc8, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fff93803fb8) at ../csu/libc-start.c:291
#9  0x0000000000403519 in _start ()

This time, of course, I don't get the value of the variables, but I assume they'd be more or less the same.

ximion · 2016-05-10T17:54:23Z

How can I help this along in the acceptance process? (eg by filing a bug on LP)

Providing feedback on https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712 would definitely help.

I think there is something else seriously wrong on your system, it actually might even be some subtle bug in libyaml...
For the critical error when moving files around, I think this is related to Docker in some way. I made the error message more verbose, so when you compile the current Git master, a bit more information on the error will be shown.

neilmayhew · 2016-05-10T18:25:59Z

I found the reason why it's looping when getting bad data. The code completely ignores errors from yaml_parser_parse!

I've fixed the problem so I'll submit a PR. It's not exactly a fix to this issue, but it's definitely an improvement. With the fix in place, the output is now:

** (appstreamcli:144): DEBUG: Data did not change, no cache refresh needed.
** (appstreamcli:144): DEBUG: Forcing refresh anyway.
** (appstreamcli:144): DEBUG: Refreshing AppStream cache
** (appstreamcli:144): DEBUG: No metadata-specific subdirectories found in '/usr/share/app-info'
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial_main_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial_restricted_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial_universe_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_main_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_restricted_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-updates_universe_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_main_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_restricted_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: Reading: /var/lib/app-info/yaml/archive.ubuntu.com_ubuntu_dists_xenial-security_universe_dep11_Components-amd64.yml.gz
** (appstreamcli:144): DEBUG: WARNING: Invalid DEP-11 file found: YAML parsing error (control characters are not allowed)
** (appstreamcli:144): DEBUG: No metadata-specific subdirectories found in '/var/cache/app-info'
** (appstreamcli:144): DEBUG: Removing old rebuild-dir from previous database rebuild.

** (appstreamcli:144): CRITICAL **: Error while moving old database out of the way.

So it gets all the way to the end, and then hits the other error. I checked the errno in gdb and it's EXDEV (18), "Cross-device link", so it's almost certainly a peculiarity of Docker, as you say.

neilmayhew · 2016-05-10T22:51:28Z

I think there is something else seriously wrong on your system, it actually might even be some subtle bug in libyaml...

I discovered a problem in my Docker test environment, which in turn is due to a subtle problem in appstream.

The compressed yaml files were being given a content type of text/plain, so the compressed data was being given to the yaml parser, which in turn returned an error that the as code ignored, and so things got stuck in a loop.

I poked around in the gio code and saw that it was using the system's MIME info, which is presumably missing in the minimal ubuntu:xenial Docker image. Installing shared-mime-info fixed this, and now the stock appstreamcli works in my Docker environment. So I think appstream should depend on shared-mime-data or a related package.

However, I still get looping with the stock appstreamcli when I enable my third-party repo. It chokes on the second dep11 file it sees. If I use a built-from-source appstreamcli without the change from my PR #36, it still loops. If I add in the change, it works. So I assume it's a victim of both bugs I've fixed (#36 and #41): the garbage bytes on the end result in a parse error which puts the code into a loop. Without the garbage bytes it never hits the loop. OTOH, if it checked for parse errors, it would at least get past the error resulting from the garbage bytes: if I cherry-pick just my change from #41, it gets all the way to the end, with a single error message in the middle:

Invalid DEP-11 file found: YAML parsing error (invalid leading UTF-8 octet)

I don't know why it gets those few garbage bytes only when processing just one of the metadata files from my repo. Maybe it's just random (ie my bad luck) or maybe because the files are much shorter than the ones already processed for the official repos. It's certainly very sensitive to environmental factors.

I'll add my feedback to LP #1579712

Nicolab · 2016-05-20T09:02:40Z

Thanks for the reactivity!

A note just for users looking to solve manually this. Because sudo apt-update is blocked (CPU 100%).

cd /tmp && mkdir asfix
cd asfix
wget https://launchpad.net/ubuntu/+archive/primary/+files/appstream_0.9.4-1ubuntu1_amd64.deb
wget https://launchpad.net/ubuntu/+archive/primary/+files/libappstream3_0.9.4-1ubuntu1_amd64.deb
sudo dpkg -i *.deb
rm *.deb
cd ..
rmdir asfix

source

neilmayhew · 2016-05-20T16:24:56Z

@Nicolab It's actually sufficient just to hit Ctrl-C when apt update hangs. Then you can do apt install libappstream3 appstream.

Nicolab · 2016-05-30T09:02:20Z

@neilmayhew 👍

ichobits · 2019-07-04T02:59:08Z

Step1 : The problem show "extended_states"
https://askubuntu.com/questions/30072/how-do-i-fix-a-problem-with-mergelist-or-status-file-could-not-be-parsed-err/183026
Use the oldest file to cp.
cp /var/backups/dpkg.status.1 /var/lib/dpkg/status

https://sathyasays.com/2009/11/08/how-to-fix-e-unable-to-parse-package-file-varlibaptextended_states-1-error-in-synaptic-or-apt-get/
E: Unable to parse package file /var/lib/apt/extended_states (1)
E: _cache->open() failed, please report
sudo mv /var/lib/apt/extended_states /var/lib/apt/extended_states_tmp

Step2 : The problem show "appstream"
https://launchpad.net/ubuntu/bionic/amd64/appstream/0.12.0-3

download the appstram file which match your system version. This file is ubuntu 18.04 LTS.
http://launchpadlibrarian.net/365002298/appstream_0.12.0-3_amd64.deb

sudo dpkg -i appstream_0.12.0-3_amd64.deb
This problem will disappear.
appstreamcli: error while loading shared libraries: libxapian.so.22: cannot open shared object file: No such file or directory
Reading package lists... Done
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi'
E: Sub-process returned an error code

sudo apt-get update
dpkg: warning: files list file for package 'libclang-common-6.0-dev' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libobjc4:amd64' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libbind9-160:amd64' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libclang1-6.0:amd64' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libclang-6.0-dev' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libclang-dev' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libisccfg160:amd64' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'libobjc-7-dev:amd64' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'lib32stdc++6' missing; assuming package has no files currently installed
dpkg: warning: files list file for package 'lib32gcc1' missing; assuming package has no files currently installed
(Reading database ... 248495 files and directories currently installed.)
Preparing to unpack appstream_0.12.0-3_amd64.deb ...
Unpacking appstream (0.12.0-3) over (0.9.4-1ubuntu1) ...
Setting up appstream (0.12.0-3) ...
AppStream cache update completed successfully.
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...

The problem is fixed.

neilmayhew mentioned this issue May 2, 2016

Ensure decompressed metadata is null-terminated #36

Merged

ximion closed this as completed in #36 May 2, 2016

neilmayhew mentioned this issue May 10, 2016

Handle errors from the yaml parser #41

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refresh hangs #35

Refresh hangs #35

neilmayhew commented May 2, 2016

neilmayhew commented May 2, 2016

neilmayhew commented May 2, 2016

ximion commented May 2, 2016

neilmayhew commented May 6, 2016

ximion commented May 7, 2016

neilmayhew commented May 7, 2016

ximion commented May 7, 2016 •

edited

neilmayhew commented May 7, 2016

neilmayhew commented May 10, 2016 •

edited

ximion commented May 10, 2016

neilmayhew commented May 10, 2016

ximion commented May 10, 2016

neilmayhew commented May 10, 2016

neilmayhew commented May 10, 2016

Nicolab commented May 20, 2016

neilmayhew commented May 20, 2016

Nicolab commented May 30, 2016

ichobits commented Jul 4, 2019

Refresh hangs #35

Refresh hangs #35

Comments

neilmayhew commented May 2, 2016

neilmayhew commented May 2, 2016

neilmayhew commented May 2, 2016

ximion commented May 2, 2016

neilmayhew commented May 6, 2016

ximion commented May 7, 2016

neilmayhew commented May 7, 2016

ximion commented May 7, 2016 • edited

neilmayhew commented May 7, 2016

neilmayhew commented May 10, 2016 • edited

ximion commented May 10, 2016

neilmayhew commented May 10, 2016

ximion commented May 10, 2016

neilmayhew commented May 10, 2016

neilmayhew commented May 10, 2016

Nicolab commented May 20, 2016

neilmayhew commented May 20, 2016

Nicolab commented May 30, 2016

ichobits commented Jul 4, 2019

ximion commented May 7, 2016 •

edited

neilmayhew commented May 10, 2016 •

edited