I give up. Marking as invalid for thumbnailer.
** Changed in: thumbnailer (Ubuntu)
Status: Triaged => Invalid
--
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
** Changed in: thumbnailer (Ubuntu)
Importance: High => Undecided
--
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
** Also affects: thumbnailer (Ubuntu)
Importance: Undecided
Status: New
** Changed in: thumbnailer (Ubuntu)
Status: New => Triaged
** Changed in: thumbnailer (Ubuntu)
Importance: Undecided => High
** No longer affects: thumbnailer
--
You received this bug notification
** Changed in: thumbnailer
Status: New => Triaged
--
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:
This bug is rather serious: we have unkillable processes on mako. It's
been over a month since I posted the reproducible test case above; is
no-one interested in fixing this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
As an experiment, I added a separate thread to vs-thumb that runs a
timer. When the timer fires (after 10 seconds), the thread calls
_exit().
When I have one of these stuck vs-thumb processes that is spinning, I
see the timer firing. However, _exit() does not terminate the process
immediately.
Here is what smemstat reports for one of the spinning processes:
25375 0.0 B11.0 M12.5 M19.1 M phablet/usr/lib/arm-
linux-gnueabihf/thumbnailer/vs-thumb
That's while the process is eating around 110% CPU. So, swap doesn't
seem to be the issue.
After running kill -9 25375,
It may be that the process is swapped out, so the delivery of the
SIGKILL takes a while for it to be swapped back in and to hence get the
signal.
To test this hypothesis:
a) one could disable swap and see if the process can be delivered the
SIGKILL and how quickly it responds to that.
** No longer affects: gstreamer (Ubuntu)
--
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:
Here is a stable link to the build artefacts: http://s-jenkins.ubuntu-
ci:8080/job/thumbnailer-devel-wily-armhf-ci/145/artifact/
--
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:
I gave michi's branch and test videos a try. For the six videos being
thumbnailed in parallel, I see two successful thumbnails, two instances
that look like they died due to invalid memory allocations:
(vs-thumb:15299): GLib-ERROR **:
/build/buildd/glib2.0-2.45.1/./glib/gmem.c:357: overflow
One other important piece of data...
While I was tinkering with this, I had a test failure on Jenkins in the
Arm build. I was watching the console log at the time and noticed that
compilation was unusually slow. Presumably, the build machine was loaded
more than usual. Then I got the following
** Also affects: gstreamer1.0 (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: gstreamer0.10 (Ubuntu)
** Changed in: gstreamer1.0 (Ubuntu)
Importance: Undecided = Critical
** Also affects: gstreamer (Ubuntu)
Importance: Undecided
Status: New
** Changed
In an attempt to diagnose this more, I ran the vs-thumb sub-processes
with strace and still managed to reproduce the problem.
Here is the code snippet that runs when we don't hear back from a sub-
process within ten seconds. (Please forgive the filthy code; this is the
result of endless hacking
One other item of info: originally, we were using QProcess::kill() and
QProcess::waitForFinished(). In that case, the hang happens inside
waitForFinished(). Attaching with gdb showed that, ultimately,
waitForFinished() ended up blocked in select().
--
You received this bug notification because
gbAnd ultimately the select() call in waitForFinished() was blocking on
a pipe that would be written to when the SIGCHLD signal handler was
called and waitid() returned the subprocess's pid. So this is
functionally the same as the direct waitpid() call.
--
You received this bug notification
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
I'm also seeing this on my Nexus 4. Except here, gstreamer hangs and
makes the process unkillable.
Here is a bit of trace from our code:
thumbnailer-service: [06:53:02.902] timeout, state = 2
thumbnailer-service: [06:53:02.902] killing process 12806
thumbnailer-service: [06:53:02.902] calling
** Changed in: gstreamer0.10 (Ubuntu)
Importance: Undecided = High
--
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
** Also affects: gstreamer (Ubuntu)
Importance: Undecided
Status: New
** Package changed: gstreamer (Ubuntu) = gstreamer0.10 (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1466273
20 matches
Mail list logo
