There I was downloading a bunch of stuff from the Internet quite happily using Firefox built-in download manager when I decided to check code academy (a site that teaches you how to program in javascript, in a cool way - apparently).

So after playing with a few exercises I got to lesson 7 (item 4) which requires you to fill the conditions of a for loop to bring i (the loop variable) down to 0. What happened is that instead of writing the loop as for (i = 2; i >= 0; i--) which would trigger the inbuilt-mechanism that would take me to the next lesson, I "mistakenly" wrote is as for (i = 2; i >= 0; i++), making the loop go on forever causing Firefox to use 100% of the CPU, frizzing everything, and frustrating all my attempts to reload the page or close the tab.

Right now I have paused the process through kill -STOP <pid>, but I don't want to close Firefox because I'm downloading a bunch of stuff that can't be resumed, and I wonder if there's a way to close this tab through the command line. Maybe there's a way to list all firefox' threads and try to close them individually (worst case, I think GDB can assist me on this).

I'm currently using Mac OS X 10.7.2.

  • 3
    Switch to Chrome, perhaps? :) – Marvin Pinto Jan 8 '12 at 19:48
  • 1
    I get the joke, haha, but that doesn't help me to achieve anything. – karlphillip Jan 8 '12 at 19:53
  • 1
    In all seriousness though, I don't think you'll be able to do what you need. Firefox, unlike Chrome, opens all tabs in the same memory space which is why one misbehaving java/flash/whatever site will bring down all your browser sessions. Probably the same reason you can't kill one tab from the command line. – Marvin Pinto Jan 8 '12 at 20:00
  • 1
    I see you're trying to close a firefox tab though the console. You should totally drop that and try jQuery. – Alex Coplan Jan 8 '12 at 20:26
  • But seriously, I don't think it's possible... stackoverflow.com/a/2076307/840973 - see the comments on the top answer – Alex Coplan Jan 8 '12 at 20:31

I did the same on Codecademy. Filled out something wrong and that resulted in an infinite loop, it seems like Codecademy isn't written to prevent such bad behavior so it gets elevated to the browser. In my case the browser just catches this and asks after a while to stop the script. I find it weird that this does not appear to be happening in your case, hence I would suggest you to upgrade Firefox after solving this so that this kind of condition can't occur again.

I'm afraid there is no way but finding a genious process management tool or attaching a debugger like gdb, this can become very tricky if you don't have any debugging information though. Just look for the thread that is somewhere in the Javascript execution routines. If you have no debug information and no dynamic libraries I guess it will be somewhere in xul.so which could be about any tab.

If you somehow figure out what the download thread is, you could attempt to freeze the other threads one by one to figure out which one is the actual tab. In the worst case freezing threads doesn't help, as the thread might be holding a lock that the other threads are waiting for. In that case you'd better just kill the process and start over with the downloads. Perhaps consider to huge downloads in a different way than with your browser, if possible...

| improve this answer | |

Just click the close-tab icon and wait, as soon as it gets CPU time it will shut it down. Or press ctrl-w (once) while the window is active, and wait.

| improve this answer | |
  • I have done that, frenetically, for the past 30 min. It's no good. – karlphillip Jan 8 '12 at 19:42

Are you on Windows? If you are, you could (conceivably) use ProcessExplorer to zero in on the misbehaving thread/s and kill it/them - just look for constant CPU/memory consumption and JavaScript function names. But be very careful - this should be precision surgery.

On other OSs, you could use a debugger to achieve the same - but it's quite a hassle.

| improve this answer | |
  • I'm on Mac OS X as I said before. I'm investigating if GDB can do the job. – karlphillip Jan 8 '12 at 20:09
  • It probably can. You could probably use Activity Monitor to help pinpoint the threads. Sadly, if I recall correctly (don't have it front of me) it will only allow killing a process - not a thread. But maybe it can save you GDB drilldowns – Traveling Tech Guy Jan 8 '12 at 20:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.