392626 - Firefox.exe often not shutting down when JAWS is running

Status: RESOLVED DUPLICATE of bug 386286

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: trunk

Often, when surfing web pages, then closing Firefox down, a Firefox process remains in Windows Task Manager. The process cannot be ended, one has to reboot the computer. Side effects of this are that all subsequent launches of Firefox behave inconsistently and result in many rendering errors for JAWS. I have observed this with Minefield builds, but never with Firefox 2.0

Reproducible: Sometimes

Steps to Reproduce:
1. Start JAWS 8.0 and Minefield.
2. Visit bugzilla pages (that's where I've often seen it happen).
3. Close Minefield.
4. Open Windows Task Manager (Control+Shift+Escape).
5. Verify: On the Applications page, Firefox is no longer listed.
6. Verify: A Firefox.exe process may or may not be present on the Processes page.
7. If it is present, highlight it, then click End Process.
Actual Results:  
Often, the window disappears, and Firefox is no longer listed in Windows Task Manager's Applications page, but on the Processes page of Task Manager, a Firefox.exe process is still running. When clicking End Process, Windows Task Manager will complain that Firefox.exe process cannot be terminated.

Expected Results:  
Firefox.exe process should completely go away from Task Manager, and no need should be to manually end its process.

Windows XP Home Edition SP2 all updates, IE 7 is also installed.

Comment 1

[Tim Keenan]

I haven't been able to duplicate this so far.

Comment 2

[Marco Zehe (:MarcoZ)]

It's still my constant companion. I almost everytime see it when going to http://www.heise.de/newsticker. It has ads that may cause this to happen, some have Flash, others don't, but there are a lot of inline frames displaying in any case.

Comment 3

[Aaron Leventhal]

I've seen firefox.exe left open before in the task manager, so that I could not launch a new Firefox because of it. However, I was able to kill the process.

When I run JAWS, then launch Firefox 3 with http://www.heise.de/newsticker and then quit Firefox, I do not get this problem.  I tried several times.

Does it do anything strange when you try this with Firefox in the debugger? Perhaps there is some infinite loop at the end (Ctrl+Alt+Break will let you stop and get a stack). Perhaps the console log will tell us something.

Comment 4

[Marco Zehe (:MarcoZ)]

I may have found a way to repro this:
1. Open Minefield. Mine automatically goes to the Minefield start page http://www.mozilla.org/projects/minefield/).
2. Go to http://live.gnome.org/Accerciser.
3. If you're not already logged in with your Gnome.org accunt, log in. I am automatically logged in on this computer.
4. Click on the EitanISaacson link.
5. The next page comes up where you are given options to edit the page etc.
6. Close Firefox.

If I have JAWS running, the Firefox.exe process hangs every time for me.

Comment 5

[Tim Keenan]

(In reply to comment #4)
> I may have found a way to repro this:

I can't duplicate that.  I checked Task Manager immediately after I shut down Minefield and the process was not to be found.

Comment 6

[Aaron Leventhal]

Marco, can you reproduce this reliably enough to get a regression range?

Comment 7

[Aaron Leventhal]

I was able to duplicate Marco's results using his steps in comment 4, but only once.

The time that it happened Firefox also had tried to install a partial update, and failed.

Comment 8

[Aaron Leventhal]

I've also been able to duplicate this twice with this bugzilla page, but then went about 5 times without it happening.

One difference is that I have no problem killing the Firefox process afterwards, but I'm not sure that's important.

Comment 9

[Marco Zehe (:MarcoZ)]

(In reply to comment #6)
> Marco, can you reproduce this reliably enough to get a regression range?

Unfortunately not. Like you've found out yourself, this thing comes and goes at its leisure. :-( Even the page I mention in comment #4 does not cause it to happen often enough that I would call it reliable.

Comment 10

[Aaron Leventhal]

Marco, does it always happen the first time you follow your steps after a new system log in or a reboot?

Comment 11

[Marco Zehe (:MarcoZ)]

(In reply to comment #10)
> Marco, does it always happen the first time you follow your steps after a new
> system log in or a reboot?

Unfortunately no. I just tried five times, and it wouldn't happen anytime. Earlier today, I got hangs four times in a row with different sites. This one is really illuding us!

Comment 12

[Marco Zehe (:MarcoZ)]

Even though I'm not able to repro this 100%, the steps given in comment #4 are still my best bet. I just reproduced it five out of six times.
One thing that might be important: I'm using the JAWS Links List (Insert+F7) to get to the "EitanISaacson" link.

Comment 13

[Aaron Leventhal]

Okay. Keep trying to get reproducable steps please. I can't think of too many more important bugs for us to fix than this one, and I need help with it.

Comment 14

[Aaron Leventhal]

Yes, the Insert+F7 could be important. If you get repro 5/6 times that sounds good enough to find the day it broke.

Comment 15

[Marco Zehe (:MarcoZ)]

Currently, it does not repro for me at all any more, even with builds that are after the day I reported the bug originally.
However I am noticing something starting with 2007-07-01 build: If I shut down this build, or any build after that, I get a slight crackling in my soundcard, as JAWS speaks the window I land in after Firefox closes. This does not happen with any prior build. The only other time I hear this crackling in speech is when my CPU is busy doing something and I try to get JAWS to speak. It's like a slight spike in CPU usage that then rapidly drops.
The checkins in this period are:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-30+00%3A00&maxdate=2007-07-01+09%3A00&cvsroot=%2Fcvsroot
Anything looking even remotely suspicious?

Comment 16

[Aaron Leventhal]

Marco, I was just browsing with ff3 and did not run JAWS, but the firefox.exe was left hanging around. I notice a couple of other similar bugs are open and CC'd you on those.

I guess it's possible to attach a debugger to the process, after this happens, to get a stack. But, are you running a build that has symbols?

It's probably worth asking the other testing gurus on #qa what to do. Maybe it's possible to send the process a crash signal so that the crash reporter comes up.

Comment 17

[Marco Zehe (:MarcoZ)]

(In reply to comment #16)
> I guess it's possible to attach a debugger to the process, after this happens,
> to get a stack. But, are you running a build that has symbols?

No, I have never seen these hangs with a debug build. To me, this appears like some sort of race condition that only gets exposed on release builds (where things happen much faster than on debug builds). I'll ask on #qa what options we have.

Comment 18

[Marco Zehe (:MarcoZ)]

I am now trying to get the hang reproduced with WinDBG running my process. Hopefully I can catch it in the hang there and get a call stack. I'll post it once I get it, here.

Comment 19

[Marco Zehe (:MarcoZ)]

Attachment: Output from WinDBG.

I managed to get a hang once. When I then chose Debug->Break, I got the Warning... shown in the file. After that, I issued the "kp" command to get the stack trace, but I don't know if this is at all useful.

Comment 20

[Aaron Leventhal]

Attachment: Output when setting XPCOM_MEM_LEAK_LOG

This is probably happening because of leaks. In fact we do leak, and need to fix that anyway. Perhaps if we look to the source of these leaks when running with JAWS we will fix this bug. It's a good starting point which we need to do anyway.

Comment 21

[Aaron Leventhal]

Marco, since you are almost always running with JAWS, how do you know for sure that it's JAWS-related? Notice that Seth Spitzer has filed some similar bugs and he doesn't run JAWS.

See bug 400489, bug 386286 and bug 400704

Comment 22

[Marco Zehe (:MarcoZ)]

I managed to get a debug build to hang. I then attached to that process using VS 2005, and when I did a Debug/Break All, I landed at this spot:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#403

This is consistent with the WinDbg output I posted in an earlier comment.

Comment 23

[Aaron Leventhal]

Aha -- that's exactly where Seth is hanging in bug 386286. I now just noticed you mentioned that in that bug.

Comment 24

[Aaron Leventhal]

I still don't see a complete stack with symbols here.

Comment 25

[Marco Zehe (:MarcoZ)]

OK, found the exact build this started happening for me. It's the build dated 2007-06-12-06, which is the first libXUL build. See bug 345517, which was checked in 2007-06-12 at 06:22 PDT. See also bug 386286.

Comment 26

[Aaron Leventhal]

Benjamin, any ideas? This was caused by the change to libxul.