Totem is 'uninterruptible'

[brad]

Binary package hint: totem

I was editing movies and repeatedly watching the outputs with Totem. After a while I checked system monitor and saw that there was a stray totem process running, and it's status was "uninterruptible". It was using less than 200KB of memory but was at 60% CPU usage continuously. I could not kill it or stop it. When I went to restart my system it took over a minute to leave the desktop, and was never able to completely shut down. I had to manually restart. :(

This only happened once, and I have no clue what caused it to happen. I have never had a problem like this before.

---------
Description: Ubuntu hardy (development branch)
Release: 8.04
Totem Movie Player 2.22.0 (2.22.0-0ubuntu3) using GStreamer 0.10.18 and GNOME

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.
 We have instructions on debugging some types of problems. http://wiki.ubuntu.com/DebuggingProcedures
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Thanks!

[Robert Nasiadek (robzon)]

I can confirm this behavior.
It happens randomly on my side. I can't really think of a way to trigger this.
Right now totem sits in the background eating 100% of one of my cpu cores and has Uninterruptible status. Can't stop it, can't kill it. All I know is that it happens when I try to close it. Its window does disappear, but the process stays in the background and eats CPU power.
What else can I say.. I'm using PulseAudio sink in gstreamer and I was listening to a shoutcast stream.
I'll post more info the next time I encounter this issue.

[Porntape (tape-buda)]

I can also confirm this behavior.
I have tried to remake the behavior that used 100% of the CPU, but couldn't. When it was eating the process power, I did a CTRL ALT BACKSPACE and logged back in again, but it didn't help, I had to restart the computer to kill the process. I didn't find this bug until I restarted so I can't really give any technical data. I have some ideas what caused it though, I hope it may help.
1. When I tried to kill the process it had a very long name with a lot of %s and numbers, not the "real" folder name of the movie (though the English part was spelled right). The movie was Korean and the Korean letters on my folder is " ¤س¤ÃÙÎ͵ ¼ÁÍÂҡ¡ʹ¤ÃѺ" probably because I don't have Korean language installed.
2. This only happens on longer movies for me, after around 1 hour.
3. This movie was from a VCD copied to the computer, so called a .dat file.

My first thoughts after seeing these posts are that none who had the bug has an English last name, and maybe the process name or link (I'm quite a noob) in other than an English language doesn't correspond to the actual folder and it can't kill it if it can't find it. I wish I had taken a screen shot of the process weird extended name, if I encounter this again, I'll send you one.

I hope this could clear up a bit.

Good luck people!

[Robert Nasiadek (robzon)]

Hello,

Porntape, thanks for joining the discussion. I can't remember which file exactly I was playing at that time, but I have no files named with non-english characters and my OS lang is english. The only characters that could get converteded are spaces (so it would give %20 after encoding).
I was playing a file either from my harddrive or from a network share with gvfs. Killing X session also didn't do much good here.

[Porntape (tape-buda)]

Hi Robert & discussion group,

I installed the Edubuntu 8.04 version on a computer for a small school to evaluate yesterday(Thailand) and I got the same problem again. I played an avi clip to start the automatic download for the appropriate codecs. Did download the two gstreamer(or spelled something close) versions. So I finally got a screenshot.

Porntape Nanakhon

[Wydarr (wydarr)]

Same thing happened for me: totem is uninterruptible, I have run a movie for about 10 minutes or so, but what I did, was I was constantly searching (using the mouse scroll wheel) for a specific part of the movie. After I've found it, I watched it (for like 2 - 3 minutes or so), and then closed totem. And ever since (it's been more than 12 hours) processor use is constantly at 100% (with totem having a variable percentage depending on what other things I do on the system) and system load at around 10.
The process name is:
10975 ? DNl 649:25 totem file:///media/Iomega/Seriale/Kyle%20XY/Kyle%20XY%20-%20Season%201/Kyle%20XY%20-%201x02%20Sleepless%20in%20Seattle.avi
Notice that the movie runs from an external HDD, which has never been disconnected, and that has NTFS file system.
Hope this helps.

[Wydarr (wydarr)]

P.S.1 When I tried to restart, the computer locked and had to do a cold reset. Probably it couldn't get the process out of the memory and refused to restart the machine. Before pressing the restart button, I tried to check whether they keyboard is working (press NumLock) but it didn't.
P.S.2 After the restart, tried to run the same flic, but didn't cause any problem now.
P.S.3 Speaking for myself, I am not very proficient in computers, so if the devs have any tasks that I can do on the computer when this happens again, that might help them determine the cause, please, post here, because I check this thread regularly.

Thanks and keep up the excellent job you have done so far!

[Wydarr (wydarr)]

And the most important, thing, that I have seen right now at the first poster:
Ubuntu 8.04 (Hardy Heron)
Totem Movie Player 2.22.1
Movie Player using GStreamer 0.10.18 and GNOME
Sorry for the three consecutive posts, but I can't edit.

[Bob/Paul (ubuntu-launchpad-bobpaul)]

Same problem for me. I was playing a WMV file with Windows Media 9 video and Windows Media 8 Audio. The video was saved on an encfs volume on the local disk, so it was using fuse (I see someone else was on fuse with NTFS, so maybe that's a pattern?)

Also of note, I see two processes with IDs 8478 and 8468 in htop, but only one with ps aux with PID
~ $ ps aux | grep totem
bobpaul 8468 80.6 3.0 557888 60836 ? DNl 18:42 31:25 totem file:///home/bobpaul/Azureus%20Downloads/Movie%20&%20Video.wmv

~$ ps aux | grep -e 8479 -e 8468
bobpaul 8468 80.1 3.0 557888 60836 ? DNl 18:42 33:52 totem file:///home/bobpaul/Azureus%20Downloads/Movie%20&%20Video.wmv

PID 8479 is Status 'R' as reported by htop. I'm not sure what that means.

[Glyph Lefkowitz (glyph)]

Interesting. I also experienced this issue, using sshfs - another fuse filesystem.

Anyone here experiencing this *not* using a fuse filesystem?

[Thomas Paris (mercen)]

I've seen the same thing happen here several times and every time with a perfectly normal and local ext3 fs (current uninterruptible instance was playing a file was on my desktop). So it seems fuse is not to blame.

Unfortunately, I have no idea how to reproduce this bug.

[Reiner Jung (prefec2)]

I ran in the same problem.
Ubuntu 8.04
totem 2.22.1
gstreamer 0.10.18

The process hang when I tried to exit totem while playing a movie.
Video stream:
  DivX MPEG-4 Version 5
  512 x 384
Audio stream:
  MPEG 1 Audio, Layer 3
  Stereo
  44100 Hz
  96 kbps

Killing with kill -9 did not work. The played file was a local file on a ext3 formatted drive. IMHO I think the problem is somewhere in the device driver either ext3 or in the block driver itself. However dmesg and all log files do not reveal any additional information. Therefore I assume no detectable crash or error happened.

Another possible problem could be associated with the audio or video output. The audio is controlled by pulseaudio on my system and the sound events still worked after totem got into this interruptible state. Therefore I assume the video-output (xv) can also be guilty part.

Because it is so hard to reproduce the bug (I just had this problem twice in the last weeks), I guess it is some sort of race condition.

The kernel is: Linux helsinki 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

For more information have a look at the lsmod, lspci and xorg.conf

Maybe some can come up with a way to reproduce this bug with this information.

[Dan Fitch (launchpad-10-dgfitch)]

I have the "unkillable process" problem without fuse or totem being involved, on a headless server install, not running X.

Was installing sbcl (sudo apt-get install sbcl) inside a screen(1) session and now the apt process and the launched sbcl (which is trying to generate some cache or something) are both unkillable with kill -9 and killall -9.

The other interesting symptom is that pstree -p reports all processes fine, but ps aux actually locks up midway through its report.

When the sbcl install locked up for over an hour, I instinctively ctrl-c'd it and ran it again without noticing the first one had not died. Now I have multiple unkillable sbcl processes; I've attached the relevant section of pstree.

The screen session that launched those processes is also now unkillable, but other processes (new and old) are behaving normally.

If I reliably duplicate this, I'll post more info.

[Glyph Lefkowitz (glyph)]

Sadly I can't remove my mistaken report against Fuse or the probably-wrong report against Totem, but the additional report of "apt-get" becoming unkillable suggests that this is clearly a kernel bug (as my original duplicate bug said).

Can anyone kernel-savvy give us some help with diagnosing or narrowing down this bug? My media center, running Hardy, seems to exhibit this bug at least once a week if I'm using totem; but, interestingly, not if I'm running VLC. If anyone has some suggested additional diagnosis, I'll switch my default media player back so that I can get those periodic crashes back and gather data. I'm keeping most of my machines on Gutsy right now because this is a reliability disaster for me (my only hardy machine requires weekly rebooting, either from compiz or totem doing this) so I'm willing to put in a bit of work to get it resolved.

[brupje (b-meijer)]

I have the same problem. Totem is marked as unkillable by the process manager, which I wouldn't care about if it weren't eating 100% cpu on one core. I can't kill the proces using kill -9 or any other way then rebooting.

[FMaz (fmaz008)]

Hi,

I also have the same problem with ubuntu, under gnome (nautilus), in french.
I tried to DELETE the file that totem was reading with sudo rm -rf ...
the file was deleted, but totem was impossible to close

tried sudo kill 5565 (the totem process id)
tried sudo pkill totem
tried to kill ans end the process with the System monitor too.

.... nothing to do.

$ ps aux | grep totem
user1 5565 99.7 3.4 181864 69940 ? DNl May30 4010:41 totem file:///home/user1/Bureau/2008_05_27_06h20m_pm.avi

[Christian Landtag (yamkaof)]

I can also confirm this program for programs other than totem.
Had this happen with a few other programs like Audacity, wine, GoogleEarth.

At the moment I have

$ ps aux | grep audacity
yamkaof 6484 0.0 1.9 44156 19976 ? D Jun10 0:00 audacity

The program went into this state right after starting it, without even opening the main window. Same with 'pq' from the universe repositories using wine. Wine itself could be killed, but not the exe it was running.

[Glyph Lefkowitz (glyph)]

FMaz, Christian -

Are you running the latest Hardy kernel, i.e. 2.6.24-18? I have not managed to reproduce this issue since I upgraded. It's intermittent though, so I'm not sure it's actually fixed...

[Christian Landtag (yamkaof)]

$ uname -r
2.6.24-18-generic

[Kjell Braden (afflux)]

Not a bug in linux-meta. The linux-meta package is only responsible for managing the kernel dependencies.

[Glyph Lefkowitz (glyph)]

Kjell, can you suggest a better package for it to be filed against? Since this bug manifests in so many different applications, it seems to clearly be in the kernel.

[Kjell Braden (afflux)]

If it's definetly in the kernel, use the "linux" package.

[Glyph Lefkowitz (glyph)]

Thanks for the pointer, Kjell. Filed against 'linux' now.

[Jeremy (jeremy-kerneltrap)]

I've noticed this happen twice now, on Ubuntu 8.04, where Totem gets into an unkillable state after I try to exit it at the end of a movie. The first time I left the system running for days, but totem never exited, just runs and runs burning CPU. Running "kill -9" as root on the process does nothing. I had not seen this before installing the 64-bit version of 8.04, though I can't confirm that this is related.

$ uname -a
Linux server 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux

I attempted to 'strace' the process, but that didn't provide any useful output.

$ ps -ef | grep totem
username 17864 1 60 10:02 ? 02:18:51 totem file:///home/username/movie.avi
$ strace -vp 17864
Process 17864 attached - interrupt to quit

I waited 5 minutes, but nothing. Seems odd, as the process is clearly eating up 100% of the CPU on one of my cores. I wasn't able to ctrl-c out of strace, I had to ctrl-z then "kill -9". "kill -15" did not kill the strace.

This errant totem process does not happen every time I watch a movie with totem, but it has happened twice in the past week, with different movies. To duplicate, I'd try running and stopping totem a few dozen times. The only way to end this process that I've found so far is a reboot.

From reading above, it sounds like this is unrelated to totem, but to be complete:

$ totem --version
GNOME totem 2.22.1

[Thomas Paris (mercen)]

Regarding kernel 2.6.24-18 possibly fixing this bug: I'm now running 2.6.24-19 and I've got an uninterruptible totem running

[Christian Landtag (yamkaof)]

I finally found what is/was causing the uninterruptible problem on my system.

After upgrading the kernel to 2.6.24-19 the programs that went uninterruptible before worked as they should. Today I reinstalled the drivers for my DVB/TV Tuner and I had the bug again. Uninstalled the drivers and modules and the programs worked flawlessly again. It seems one of the modules that is build to support the tuner causes the bug on my system although the same drivers caused no trouble under Gutsy but it began after the upgrade to Hardy.

I would rule out the drivers themselves as the source for the bug because as I mentioned there were no problems under Gutsy and I tried two different versions of the drivers, both with the same result.

So could it be a bug with the way Hardy builds modules or with the kernel source used for building them?

[Christian Landtag (yamkaof)]

Sorry for the double post but I just thought if the problem is caused by certain modules could it be that the uninterruptible processes only come up when a certain module is loaded for example when some device is attached or switched on, while the bug doesn't happen when the module is unloaded and the device not attached or switched of?

[Michele Michielin (michele-michielin)]

I'm sometimes having the same problem: totem uninterruptible eating 100% CPU and 44 MB memory..., unable to reboot the machine.
This is a very disturbing bug since tou cannot kill the process and neither reboot the machine!

Linux ubuntu-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:15:37 UTC 2008 x86_64 GNU/Linux
Ubuntu 8.04 on AMD64

[Paul Natsuo Kishimoto (khaeru)]

Also experiencing this bug on:
Linux khaeru-desktop 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux
...with no useful information beyond what has already been posted.

As Glyph Lefkowitz says, someone kernel-savvy needs to try and reproduce this and see what's going on. I am the 14th person to echo brad's original report, so it seems reasonable to mark this as "confirmed" in linux, but not in Totem per Christian Landtag's comment about audacity, wine, etc.

This may be wrong, but I'm unsure of how to get developer acknowledgement or attention otherwise. The behaviour is evidently not chimerical and the posters here (or at least I) are clearly beyond our depth in terms of figuring out precisely what is happening. Pedro Villavicencio, is the information already provided not sufficient to diagnose or fix the bug? If not, what else can we do to provide it? Kjell, since you seem to know more than most commenters about the kernel packages, can you suggest someone to provide guidance in reporting? Your feedback on ours is appreciated.

[bisybackson (bisybackson)]

Just happened to me too, symptoms are exactly as the posts above.

It may or may not be relevant that the DVD-RW drive in my laptop popped open while it was busy mounting the disk. It reported "Unable to mount" on the desktop, after which I closed the drive door again. It mounted and autoplayed the DVD movie in Totem. I closed Totem and am now stuck with the uninterruptible process.

Hardware is a Thinkpad Z60m with DVD Multi recorder drive thing
Linux tinkpad 2.6.24-19-generic
GStreamer 0.10.18
Totem 2.22.1
Using PulseAudio

[Galileon Galilei (galileon)]

same problem

user@computer:~$ ps -o pid,sig,wchan,state,cmd -p 12483
  PID PENDING WCHAN S CMD
12483 0000000000044100 - D totem file:///home/user/movie.avi

Linux carybdis 2.6.24-19-generic #1 SMP Wed Jun 18 14:43:41 UTC 2008 i686 GNU/Linux

Pentium D 930, 1 GB Ram, ASUS P5ND2, SATA 2 WD HDD

bug stops computer from hibernating

also, this was a good time to install updates and reboot!

[darthanubis (darthanubis)]

Linux ubuntu 2.6.24-19-server #1 SMP Wed Jun 18 14:44:47 UTC 2008 x86_64 GNU/Linux

Same thing with my situation. Totem goes ape, causing a reboot to release the computer from this process. This is not good.

[Thomas Paris (mercen)]

It's just happened to me once again, but this time I was running it from a terminal. The last (and I think only relevant) message was:

E: thread-posix.c: Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:194, function pa_tls_set(). Aborting.

I had recently seen a blog post suggesting pulseaudio might sometime be responsible for uninterruptible processes. Well, it seems to me like this message confirms it (the assertion is thrown from pulsecore).

HTH

[qweadawdq (asdasdasd1q2wqeq)]

Yes i also got this, 23-july-2008 with all the updated done.

the Assertion failed and the fact that i also had problems with it, tells me its the damn PULSEAUDIO again :S

Why is it so buggy?

Often i have to kill "pulseaudio" because it got stuck (altough killable) after amarok or audacious....

this is a REAL BAD ubuntu problem :(((

[Paul R Alexander (paul.r.alexander)]

Just wanted to confirm this is happening in other apps, Pidgin in my case.

Pidgin 2.4.1
Kernel 2.6.24.19.21 (latest)
Ubuntu 8.04

I closed Pidgin using the right-click menu in the panel. After a bit it hadn't closed and I was presented with a box saying the program couldn't shut down, would I like to "wait" or "force quit". I chose "force quit" and locked the computer. Came back 14 hours later and Pidgin is still running, shows as "uninterruptible" in System Monitor".

Tried:
kill -9 pid
killall pidgin
Kill from System Monitor
End from System Monitor

All have no effect

[Glyph Lefkowitz (glyph)]

As Thomas Paris reports, this probably isn't caused by fuse, since he had it occur in a situation where fuse was not being used.

[BlueWine (james-blue-wine)]

Would like to say I'm also having this problem. It happens rather regularly too. This time Pidgin is affected, it's uninterruptible and is hovering around the 70% CPU range, sometimes climbing to 100%. All the files it seems to have open are *.wav files, so that may point to it being PulseAudio?

Seems to happen to a random program (usually the one opened last) which is trying to play sound - Firefox 3 and Pidgin have been affected so far. Weirdly, however, I have killed PulseAudio, restarted RhythmBox and it's still playing! Even though it hasn't restarted PulseAudio, so maybe I'm not killing the right thing (or maybe RhythmBox doesn't use PulseAudio, which might therefore point to another culprit not releasing the sound device? Stabs in the dark..)

It presents itself by making my system sluggish, but not unusable, so I'll leave it on with the program in the background for a little while, see if it relents.

If you need more details or for me to test anything, please let me know. It happens rather regularly to me so I'm sure I can get a result of an experiment quite quickly ^_~

[BlueWine (james-blue-wine)]

Haven't been able to get it to crash today. However, I have observed some odd behavior:

If I play a youtube, rhythmbox won't play at the same time. When the Youtube ends, I have to restart Rhythmbox for it to play again. Same with VLC. However, if I leave my Rhythmbox playing, Youtube can't play sounds. I have to close Rhythmbox, then close Firefox, and then re-open.

Now, I spend hours on end playing from my Rhythmbox library or my VLC video (ahem) collection, whilst browsing the internet. The internet is full of flash with music, which I usually watch soundless if at all. But we're talking hours without closing these programs.

So, I suppose my question is, has this got to do with the way that Adobe's Flash is interfacing with the sound card? If so, is there a buffer that's filling and filling until it sends errors back to the program filling it? Or not sending a confirmation, leaving the program to keep the request open? This is pseudo-techie talk, so bear with me here, but it would explain why Pidgin still had 6-7 sound files open once the program was meant to be closed.

Thing is, Pidgin, Totem and Rhythmbox usually play well together. So is Adobe-Flash what's throwing the spanner in the works? Has anyone else affected by this got Adobe-Flash on their system?

It's another stab in the dark - I'll update when it crashes tomorrow ;)

[Nenad Radulovic (blueskyniss)]

@BlueWine

You can check this thread regarding PulseAudio and Flash issues, it sure helped me:

http://ubuntuforums.org/showthread.php?p=4928900

also check the new thread at:

http://ubuntuforums.org/showpost.php?p=5587712&postcount=472

[BlueWine (james-blue-wine)]

Hey,

Tried those steps (apart from Part D, I understand that's just to add an equaliser to improve sound quality?) but it hasn't made any obvious differences. Flash still doesn't play nicely with the rest of the world, as before.

I'll keep trying to crash it! ^_~

[Nenad Radulovic (blueskyniss)]

Too bad then...hopefully this and sound issues will be fixed soon :)

[Thomas Paris (mercen)]

It's not a problem with flash as I haven't got any flash plugin installed.

[BlueWine (james-blue-wine)]

That 'fix' actually made things less usable. If I was running Flash, Rhythmbox would finish what it was playing then stall when starting the next song. The only solution was to close everything that was using sounds (Firefox, Pidgin, Rhythmbox) and start it all up again.

Whatever what 'fix' did must've made Flash queue for use of the sound card, but Flash still wasn't releasing the card afterward. Psuedo-techie guess anyway ^_~

I have reverted, will keep updating as I progress.

[David Hof (david-hofstee)]

I can confirm that totem-gstreamer on my kernel,

Linux xiliance 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux

has the same behaviour. The file is read from a normal hdd. I found a few interesting lines in /var/log/messages:

Aug 19 22:40:30 xiliance kernel: [100177.937925] totem[28217]: segfault at ae600000 eip b258f468 esp afd4cc70 error 4
Aug 19 22:40:30 xiliance kernel: [100177.945805] totem[28208]: segfault at 07c1faf6 eip b7353054 esp bfa51620 error 4
Aug 19 22:40:30 xiliance kernel: [100177.945823] totem[28214]: segfault at 07bbecf6 eip b736dbfc esp b35ae3b0 error 4
Aug 20 10:07:14 xiliance kernel: [140415.517044] totem-gstreamer[28369]: segfault at 00000000 eip b780179e esp bfa93420 error 4

Only the last line actually caused a 'stuck process'.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Ravindra Singh (r-singh)]

I can confirm this bug...Just watch a video and close Totem... The interface closes but background process running.

The Totem process is marked with "uninterruptable" and uses 90 to 100% CPU (dual core!)

[tony_s (tony-sauma)]

I tried to add my comment before but I cannot see it yet, so I'll try again. I wonder if Ubuntu has changed "classical" Unix privilege settings , and if that might be the problem. I have exactly the same problem with Totem becoming uninterruptible. I watch a movie and close the window. The GUI disappears but the process seems to survive. I have managed to set a password for root and I cannot kill -9 the process. Now here is my question. I work with both Solaris, HP-Unix and Linux. I have never seen a case where root cannot kill -9 a process. In the Unix signal definitions, you can read that the 9-signal is not catchable by any process, and root should have the right to send any signal to any process. Why on earth is the process not dying? Does this occur on other flavors of Linux, like Suse, Mandriva or Slackware? Has Ubuntu (and possibly Debian) modified the privileges of root?

[Robin Sheat (eythian)]

tony_s: I doubt it's a permissions/privileges issue. My guess is that there is a kernel bug of some type going on and the process gets wedged in there, and so is unkillable until it returns, which never happens. In #225654, I posted a bit more detail about where I saw it getting stuck, in my case it's in a call to 'exit_mm'.

[tony_s (tony-sauma)]

Eythian, It's not a permissions issue, still I wonder why root cannot kill -9 a process. Maybe there are cases when this occurs, but I've never seen that before. Whenever I've typed kill -9 <pid> as root I've been able to get rid of the process.

[Glyph Lefkowitz (glyph)]

Still happening, updated to the latest everything in Hardy.

This time I made a tarball of /proc/<pid> of the affected process; I can upload bits of that if it would be helpful to anyone.

I checked in /var/log/kern.log and discovered that a totem segfault immediately preceded the unkillable process, but several other totem segfaults had occurred recently apparently with no ill effect.

Haven't seen this on any other hardy machines though.

[jorritlinnert (jorrit-linnert)]

Glyph Lefkowitz, could you be a little bit more specific about "the latest everything", for instance: What kernel version (uname -a) are you running?
If you are not running one of the latest kernels (.26 or .27) I am willing to test those against this bug.
I might even be tempted to reinstall totem for test purposes (I have never liked that player)

[Glyph Lefkowitz (glyph)]

glyph@suijin:~$ uname -a
Linux suijin 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686 GNU/Linux

As far as I'm aware, this is the latest Hardy kernel, not an updated Intrepid kernel.

Good luck reproducing the bug, I have not been able to find a reliable way to do so.

[Glyph Lefkowitz (glyph)]

Can someone from the kernel team please indicate what information would be useful in investigating this problem? It still occurs for me periodically, and I would be more than happy to spend some effort gathering diagnostics when it does.

[sarton85 (sarton85)]

Totem was also uninterruptible on my system after I was watching a flash movie which I downloaded from Youtube. I couldn't kill totem in the system monitor, so I tried to kill it with "sudo kill <process id>", that also didn't work. When restarting my system ubuntu logged out, but didn't want to go back to the boot screen, so I had to force reboot my computer.

I am on a fully upgraded Ubuntu Intrepid Beta amd 64 system. I am using Intrepid since it's alpha 5 stage and didn't have this problem before.

Totem version: 2.24.2
GStreamer version: 0.10.21
swfdec-gnome version: 2.22.2-2
Kernel version: 2.6.27-6-generic
Ubuntu version: Intrepid Beta

[Tesuki (tesuki-deactivatedaccount)]

I have also been effected by this bug. in fact there are a uninterruptible totem process in the background now. and are using 100% of one CPU core.

kernel 2.6.24-21-generic x86_64
ubuntu hardy heron 8.04
totem 2.22.1
GStreamer 0.10.18

if I should trust gnome system monitor (right click and choose Open Files) then the last played move was a .avi file on a SW raid array with raid level 5.
while watching I had firefox, pidgin, Transmission, Rhythmbox and evolution running in the background.

don't know really if I can add any more info that hasn't been added.
I will probably not turn of my computer in a while so if I should check anything special then tell me to.

[Robin Stocker (nibor)]

Tesuki: It may be that the bug is in pulseaudio (see the upstream bug report). What version of pulseaudio do you have?

I'm running on Intrepid and haven't had this bug in a while, so maybe it's already gone.

[Glyph Lefkowitz (glyph)]

Robin: the bug is not in pulseaudio. It's in the kernel. Given that pulse doesn't ship any kernel drivers, there's nothing that it should conceivably be able to do to block "kill -9".

dreamsare4living seems to indicate that the bug is still present in intrepid.

[roel (m9dhatter)]

pulse-audio seems to have an effect.
i can reproduce with skype and pidgin.
this has just been upgraded with ibex.

1. launch pidgin.
2. launch skype and start a conversation.
3. end the conversation
4. skype will not play nice pulse audio (will notice by not being able to start a new conversation in skype)
5. kill pulse-audio
6. skype is ok again
7. pidgin will hang and refuse to die.

Linux michelle 2.6.27-3-generic #1 SMP Wed Sep 10 16:02:00 UTC 2008 i686 GNU/Linux

[Silvio Ricardo Cordeiro (silvioricardoc)]

This is not Hardy-specific. Running Intrepid. It's a kernel bug, and still in 2.6.7.
uname -a: Linux ricardo-desktop 2.6.27-10-generic #1 SMP Fri Nov 21 12:00:22 UTC 2008 i686 GNU/Linux.

It's the same thing here. Totem in uninterruptible sleep, can't be killed.
The kernel is stuck in exit_mm, after scheduling out the process.

I tried to attach gdb to it, but gdb is [code]wait[/code]ing for totem.
Try to SIGTERM gdb, and it asserts from "linux-nat.c:1072".
(Not sure if this will help, though...)

The following message is output to /var/log/syslog, /var/log/kern.log and /var/log/messages
every 2 minutes (sometimes, it's printed more than once at one time):

Dec 13 09:18:38 ricardo-desktop kernel: [161877.321406] INFO: task totem:27754 blocked for more than 120 seconds.
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321409] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321411] totem D c011fd28 0 27754 1
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321415] f4cdbe70 00200082 f4cdbe0c c011fd28 00000000 00000a28 ac474000 00000000
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321422] 0000000f 00000000 c22a3240 0010fb27 00000000 00200246 00000000 f5028340
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321428] c050f080 c7ba0000 f4cda000 c22a34b8 c1b4dd00 00000000 ac474e10 c1b4dd00
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321435] Call Trace:
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321437] [<c011fd28>] ? kmap_atomic_prot+0x48/0x100
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321442] [<c01340f5>] exit_mm+0x75/0x130
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321445] [<c0135e1d>] do_exit+0x13d/0x360
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321449] [<c013ce23>] ? recalc_sigpending+0x13/0x40
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321453] [<c013e670>] ? dequeue_signal+0x30/0x180
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321457] [<c0136075>] do_group_exit+0x35/0xa0
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321460] [<c0140093>] get_signal_to_deliver+0x183/0x3a0
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321464] [<c0123186>] ? set_next_entity+0x126/0x160
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321468] [<c0103da8>] do_notify_resume+0x78/0x160
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321472] [<c01284cb>] ? finish_task_switch+0x2b/0xe0
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321476] [<c037cf89>] ? schedule+0x429/0x790
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321481] [<c0153230>] ? tick_program_event+0x30/0x40
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321485] [<c0113f8d>] ? smp_apic_timer_interrupt+0x5d/0x90
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321490] [<c0380e90>] ? do_page_fault+0x0/0x720
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321494] [<c0104140>] work_notifysig+0x13/0x23
Dec 13 09:18:38 ricardo-desktop kernel: [161877.321498] =======================

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[jaduncan (jaduncan)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[sarton85 (sarton85)]

@jaduncan

For me it is not an issue at this right moment, as I am on Debian 5.0. I have been on Intrepid for a while after it became stable in October and also didn't encounter this issue anymore.

[Robin Sheat (eythian)]

While not definitive, I can't say that I've seen it for a while either.

[Reiner Jung (prefec2)]

The problem looks solved to me.

[darthanubis (darthanubis)]

I'm using 9.04 and all is well.

[roel (m9dhatter)]

not definitive but yeah, i can't say i've seen it. skype is still funky with pulse audio though.
using 8.10.

[Michele Michielin (michele-michielin)]

I'm using 8.10 and the problem looks solved to me also.
Thanks

[aschuring (aelschuring)]

I ran into this same (well, appears to be same) bug with a Debian kernel (2.6.26). See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515009

Like this bug, I have been unable to reproduce it or even stumble upon it a second time.

[jaduncan (jaduncan)]

All bug participants confirm a fix.

[zorpox (nononinono)]

Unfortunately, this bug is not solved, as I'm experiencing it right now. Totem eats 100% cpu and is completely nonresponsive. Killing X did not help, nor did "kill -9 pid". I'm running a fully upgraded clean intrepid install.

[bambrikii (shurik-a3-2)]

Linux version 2.6.24-23-generic (buildd@crested) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3))

Totem Movie Player 2.22.1 (GStreamer 0.10.18) eats a lot of cpu time after trying to play an incompletely downloaded file. The hung process cannot be killed.

Reboot required to get rid of this process.

asd@asd-laptop:~$ ps aux | grep totem
asd 10144 74.7 5.3 779140 164980 ? DNl 03:29 25:42 totem file:///mnt/.../VIDEO_TS/VIDEO_TS.VOB
asd 11666 0.0 0.0 5168 856 pts/3 S+ 04:03 0:00 grep totem

asd@asd-laptop:~$ lsof -p 10144
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
totem 10144 asd cwd DIR 8,3 4096 1440104 /home/asd/.azureus
totem 10144 asd rtd DIR 8,3 4096 2 /
totem 10144 asd txt REG 8,3 413416 3274513 /usr/bin/totem-gstreamer
totem 10144 asd DEL REG 0,9 30769314 /SYSV00000000
totem 10144 asd DEL REG 0,9 30736545 /SYSV00000000
totem 10144 asd DEL REG 0,9 30703776 /SYSV00000000
totem 10144 asd DEL REG 0,9 30671007 /SYSV00000000
totem 10144 asd DEL REG 0,9 30638238 /SYSV00000000
totem 10144 asd DEL REG 0,9 30605469 /SYSV00000000
totem 10144 asd DEL REG 0,9 30572700 /SYSV00000000
totem 10144 asd DEL REG 0,9 30539931 /SYSV00000000
totem 10144 asd DEL REG 0,9 30507162 /SYSV00000000
totem 10144 asd DEL REG 0,9 30474393 /SYSV00000000
totem 10144 asd DEL REG 0,9 30441624 /SYSV00000000
totem 10144 asd DEL REG 0,9 30408855 /SYSV00000000
totem 10144 asd DEL REG 0,9 30376086 /SYSV00000000
totem 10144 asd DEL REG 0,9 30343317 /SYSV00000000
totem 10144 asd DEL REG 0,9 30310548 /SYSV00000000
totem 10144 asd DEL REG 0,9 30277779 /SYSV00000000
totem 10144 asd DEL REG 0,9 30245010 /SYSV00000000
totem 10144 asd DEL REG 0,9 30212241 /SYSV00000000
totem 10144 asd DEL REG 0,9 30179472 /SYSV00000000
totem 10144 asd DEL REG 0,9 30146703 /SYSV00000000
totem 10144 asd DEL REG 0,9 30113934 /SYSV00000000
totem 10144 asd DEL REG 0,9 30081165 /SYSV00000000
totem 10144 asd DEL REG 0,9 30048396 /SYSV00000000
totem 10144 asd DEL REG 0,9 30015627 /SYSV00000000
totem 10144 asd DEL REG 0,9 29982858 /SYSV00000000
totem 10144 asd DEL REG 0,9 29950089 /SYSV00000000
totem 10144 asd DEL REG 0,9 29917320 /SYSV00000000
totem 10144 asd DEL REG 0...

[littlemike (fletchermichael)]

Bug still present on 8.04. Fully up-to-date system. uname: "Linux linux1 2.6.24-24-generic #1 SMP Tue Jun 30 19:54:36 UTC 2009 x86_64 GNU/Linux"

Was playing a flash video, totem burped out an error when I closed it (the pulseaudio error I believe). Now totem is embedded like a tick eating 100% of one cpu and won't die. kill -9 has no effect.

[MinsEcho (minsecho)]

I know fairly well what I am doing to cause this same problem for myself... but not why.

root@Murphy:/home/echo# uname -a
\Linux Murphy 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 19:49:51 UTC 2009 i686 GNU/Linux

root@Murphy:/home/echo# ps aux | grep totem
echo 4001 7.4 4.7 191324 48892 ? D 12:14 23:18 totem /home/echo/.gvfs/media on bcz/music/Blue Man Group/The Complex/Above.mp3
root 11562 0.0 0.0 3336 800 pts/1 S+ 17:32 0:00 grep totem

Note that the file is on a Windows XP machine on the local network.
I do not know why, but this problem has not failed to occur for me any time I do the following:
- I played a playlist of networked audio files earlier in the day
- I left and came back over 2 hours later
- I hit play to start the playlist again and Totem stopped responding
I know that Totem could not find the file because Nautilus also could not find the file; when I refreshed the folder view, Nautilus alerted me that the directory was unavailable:

Could not display "smb://bcz/media/music/Blue%20Man%20Group".
Error: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Please select another viewer and try again.

Note, it just told me some possible problems that could be occurring, and of these, I "feel" like the last, "network connection was broken" seems to be the most likely in my case (the other computer "falls off of the network," for no apparent reason, on a regular basis).

Totem, on the other hand, is still hanging, still "Uninterruptible" and waiting for a response. The "Waiting Channel" in the System Monitor reads "request_wait_answer"
Unlike other people in this thread, my totem is not utilizing any noticeable CPU time.

One thing I have wondered - does SMB/CIFS have a time-out that disconnects the network channel?

As of now, when I save this comment, it will have been uninterruptible for over an hour, the longest I have let it stay that way yet.

Gosh, I kinda want to ask if there is a way that I can send an answer to totem :)
I hope this information helps.

[MinsEcho (minsecho)]

This might also be useful:

root@Murphy:/home/echo# ps aux |grep gv
echo 3302 0.0 0.2 5748 2112 ? S 11:58 0:00 /usr/lib/gvfs/gvfsd
echo 3308 0.0 0.2 46588 2788 ? Ssl 11:58 0:03 /usr/lib/gvfs//gvfs-fuse-daemon /home/echo/.gvfs
echo 3425 0.0 0.2 6104 2876 ? S 11:58 0:00 /usr/lib/gvfs/gvfsd-trash --spawner :1.5 /org/gtk/gvfs/exec_spaw/0
echo 3427 0.0 0.3 32432 3760 ? Sl 11:58 0:00 /usr/lib/gvfs/gvfs-hal-volume-monitor
echo 3429 0.0 0.3 8220 3100 ? S 11:58 0:00 /usr/lib/gvfs/gvfs-gphoto2-volume-monitor
echo 3464 0.0 0.2 5616 2228 ? S 11:58 0:00 /usr/lib/gvfs/gvfsd-burn --spawner :1.5 /org/gtk/gvfs/exec_spaw/1
echo 3976 0.0 0.3 14780 3308 ? S 12:14 0:00 /usr/lib/gvfs/gvfsd-network --spawner :1.5 /org/gtk/gvfs/exec_spaw/2
echo 3979 0.0 0.5 25192 5884 ? S 12:14 0:00 /usr/lib/gvfs/gvfsd-smb-browse --spawner :1.5 /org/gtk/gvfs/exec_spaw/3
echo 3983 0.0 0.2 5784 2388 ? S 12:14 0:00 /usr/lib/gvfs/gvfsd-dnssd --spawner :1.5 /org/gtk/gvfs/exec_spaw/4
echo 3993 31.1 0.5 24048 5384 ? Sl 12:14 124:11 /usr/lib/gvfs/gvfsd-smb --spawner :1.5 /org/gtk/gvfs/exec_spaw/5
echo 4001 5.8 4.7 191324 48892 ? D 12:14 23:18 totem /home/echo/.gvfs/media on bcz/music/Blue Man Group/The Complex/Above.mp3
echo 9201 0.0 0.4 22948 4936 ? S 16:46 0:00 /usr/lib/gvfs/gvfsd-smb --spawner :1.5 /org/gtk/gvfs/exec_spaw/6
root 13478 0.0 0.0 3340 808 pts/1 S+ 18:53 0:00 grep gv

In particular:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
echo 3993 31.1 0.5 24048 5384 ? Sl 12:14 124:11 /usr/lib/gvfs/gvfsd-smb --spawner :1.5 /org/gtk/gvfs/exec_spaw/5

In System Monitor, this process is actually listed at 47% CPU and 1.4MiB Memory.

Also, I noticed a typo in my previous post: a slash got inserted at the beginning of my "uname -a" response; please ignore it.

[Glyph Lefkowitz (glyph)]

Is there any way to get from the comment above to a changeset or revision number or release which fixed the bug? Or even what the problem was actually determined to be? The discussion above is all very vague. I am especially confused because this went from "new" to "fix released" without an intermediary "fix committed".

[Martin Mai (mrkanister-deactivatedaccount-deactivatedaccount)]

Glyph, the change "New -> Fix Released" happened in the project "PulseAudio" (have a look at the top of this bug for that). Next to it there is a bug number. If you follow the link you get to the bug in the upstream bug tracker (upstream is where the developers of the software are and fix the bugs, we then pull the new package version). This helps us keeping track of the progress.

If you read through the comments in the upstream bug you'll see that it says:

>>>
    * status changed from new to closed
    * resolution set to fixed
    * milestone set to 0.9.16

This was a problem with dlunloading modules if I remember. Which has been fixed a while back in PA. Closing
<<<

In this case they actually provid a version number the bug fix will be present in: 0.9.16

Then, we (the bug triagers) will have a look at the version that is currently in ubuntu ("rmadison" is a great tool for that):
*snip*
pulseaudio | 1:0.9.14-0ubuntu20.2 | jaunty-updates | source, amd64, i386
pulseaudio | 1:0.9.16~test4-0ubuntu4 | karmic | source, amd64, i386

You can see that the development version karmic already ships with a "test"-version of 0.9.16 so this bug might already be fixed. After some testing feedback (best from the bug reporter, because he had the problem) the bug can be closed :).

[Glyph Lefkowitz (glyph)]

Martin,

Thanks very much for your explanation. That's a slightly convoluted path to follow; it would be very helpful if Launchpad had a more direct feature that allowed us to see the relationship.

However, until it does, your explanation is very useful and it will help me understand future ticket status updates :).

[Sebastien Bacher (seb128)]

the issue is not a totem one

[Alejandro R. Mosteo (mosteo)]

I'm sorry for posting in this old bug, but I'm having this issue with yet another program. See for yourself this sequence of commands:

$ sudo -s
# uname -a
Linux tacitus 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux
# ps ax | grep amule | grep -v grep
 2912 ? R 326:29 amule
# kill -9 2912
# kill -9 2912
# ps ax | grep amule | grep -v grep
 2912 ? R 326:43 amule
# kill -SIGSTOP 2912
# ps ax | grep amule | grep -v grep
 2912 ? R 326:52 amule
# ps aux | grep amule | grep -v grep
jano 2912 82.5 1.0 96156 39396 ? R Dec14 327:26 amule

Basically, the process is impervious to two signals that should have some effect. Meanwhile, its window is frozen and it consumes 100% of one CPU.

I have several up-to-date maverick machines, and this is the only one exhibiting this problem, so perhaps it is dependent on some hardware component.

[Laurynas Riliskis (laurynas-riliskis-gmail)]

Same problem appeared in 11.04 somewhere in latest updates. More ever the totem was running at 100% CPU. the upstart was random and I had to uninstall it because my laptop was going way to hot because of it.

[Wayne Rodrigues (waynerod10)]

Sorry for bumping up an old bug, but it it still happening. It's happening to me Right now!!

---------------------------------------------------------------------------------------------------------------------
  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17893 wayne 39 19 252m 9988 6476 S 99 0.5 0:08.62 totem-video-thu
---------------------------------------------------------------------------------------------------------------------

CPU is like 99% to 100%. I tried killing it by PID, but then it just gets a new PID and keeps running.... Any way to stop this?? My laptop is getting real hot!!

[Robin Sheat (eythian)]

I think that's a different thing. The problem here was with processes that didn't respond to a kill. If they get a new PID, then they are being killed and something else is firing them up again.

Probably you have a file that is causing the thumbnailer to get stuck, I'd try to figure out what that file is (lsof will help here) and file a new bug on it.

[Alejandro R. Mosteo (mosteo)]

According to a report today in bug 925309, the kernel part of this might have been fixed, making the processes killable. Also, if bug 913787 is correct, ecryptfs might have a hand on these 100% CPU processes (although not necessarily in the totem case, where I agree with comment #88).

[Po-Hsu Lin (cypressyew)]

Closing this bug with Won't fix as this kernel / release is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!