Here is a reproducible test case. $ system-image-cli -i current build number: 229 device name: mako channel: ubuntu-touch/devel-proposed/ubuntu last update: 2015-06-18 07:16:41 version version: 229 version ubuntu: 20150618 version device: 20150529.1 version custom: 20150618
The code was built from this branch at revision 238: https://code.launchpad.net/~michihenning/thumbnailer/no-download-for- failure-cache-hit The debian packages are: http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-devel-wily-armhf-ci/lastSuccessfulBuild/artifact/work/output/thumbnailer-common_1.4bzr238pkg0wily145-0ubuntu1_all.deb http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-devel-wily-armhf-ci/lastSuccessfulBuild/artifact/work/output/thumbnailer-service_1.4bzr238pkg0wily145-0ubuntu1_armhf.deb http://s-jenkins.ubuntu-ci:8080/job/thumbnailer-devel-wily-armhf-ci/lastSuccessfulBuild/artifact/work/output/qtdeclarative5-ubuntu-thumbnailer0.1_1.4bzr238pkg0wily145-0ubuntu1_armhf.deb To reproduce the problem, install the debs and untar the attached archive into an empty directory somewhere. Run top in another terminal. Now, from within the video directory, run the following script: #!/bin/sh for i in video*.mp4 do /usr/lib/arm-linux-gnueabihf/thumbnailer/vs-thumb fd://0 $i.jpg <$i & done wait This fires as many vs-thumb instances concurrently as there are video files (see below). It's possible that the script will terminate without error. (The fewer videos there are, the more likely it is to succeed.) If it succeeds, just try again. Eventually, the script will not terminate, and top will show one or more hung vs-thumb processes that are consuming 100% CPU each. Here comes the good bit. (You may have to try this several times but, eventually, you'll see the problem.) >From another terminal, run kill -9 <hung-vs-thumb-pid> Quite often, it'll kill the process as it should. But, every now and then, it doesn't. Instead, the hung vs-thumb keeps hanging around, still consuming 100% CPU until, pretty much exactly 30 seconds later, it exits. So, the kill -9 doesn't kill until 30 seconds later in some cases. While experimenting with all this, you will most likely also see this: Error creating thumbnail: ThumbnailExtractor: change_state(): reading async messages: GStreamer error: negotiation problem. This error is unrelated and can be reproduced on the desktop by just running a single vs-thumb at a time in a loop. On my Core i7, I get this once every two-hundred iterations or so. You will probably also see (vs-thumb:26741): GLib-ERROR **: /build/buildd/glib2.0-2.45.1/./glib/gmem.c:357: overflow allocating 4294967274*8 bytes That happens when there are too many vs-thumb processes. It doesn't seem to be happening with only four concurrent gstreamer processes. You can show this by moving two of the videos out of the directory. However, the allocation problem is *NOT* related to the signal issue. The signal issue can be reproduced even when this allocation failure doesn't occur, with only four concurrent vs-thumb processes. The source code for vs-thumb is in the thumbnailer project, in src/vs- thumb. There isn't a lot of code there (around 400 lines), so it's quite easy to see what's going on. ** Attachment added: "videos.tar" https://bugs.launchpad.net/ubuntu/+source/gstreamer1.0/+bug/1466273/+attachment/4420242/+files/videos.tar -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1466273 Title: gstreamer fails intermittently To manage notifications about this bug go to: https://bugs.launchpad.net/thumbnailer/+bug/1466273/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
