© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Here is a reproducible test case.
$ system-image-cli -i
current build number: 229
device name: mako
channel: 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:/
The debian packages are:
http://
http://
http://
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/
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/
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.