400310 - Deadlock when Thunderbird starts with Accessibility, or when Firefox starts after an auto-update, effective 2007-10-07

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Marco Zehe (:MarcoZ)]

When running Thunderbird with a screen reader on Windows, after launching it runs into a deadlock that eats up all remaining CPU cycles and brings the machine down to a crawl. Once focus shifts to a different control via keyboard or via mouse activities, the deadlock is released.
The same happens with Firefox, when it starts after an auto-update has been applied. Other launches do not reveal this deadlock with Firefox.

The first build this happens in is Firefox and Thunderbird from October 7, 2007. The checkins for 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-10-06+00%3A00&maxdate=2007-10-07+05%3A45&cvsroot=%2Fcvsroot

In building a debug build, attaching to the process, and then breaking, I was thrown into this file on this line:
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsAppShell.cpp#154.

To see the effect, simply download and run a screen reader like JAWS, or NVDA, and then start a current Thunderbird Trunk build. Or, start a fairly recent Minefield build and let it auto-update, then watch the effect after the update has been applied.

Comment 1

[Aaron Leventhal]

If this is because of auto update, I really think it's probably bug 340535.

The problem has that AccessibleMarshal.dll is being used and can't be removed.

Comment 2

[Marco Zehe (:MarcoZ)]

(In reply to comment #1)
> If this is because of auto update, I really think it's probably bug 340535.

I do not think so.
1. It hangs *every time* I start Thunderbird, starting with builds Oct 7, 2007.
2. The auto-update of Firefox completes successfully before I get the deadlock. If it were because of AccessibleMarshal.dll, which I have also seen come up, Firefox warns me about this and quits the auto-update process without hanging.
So this is a new issue, not a dupe of the bug you quoted.

Comment 3

[Tim Keenan]

I couldn't reproduce this updating to today's build of Minefield from yesterday's, using Window-eyes.  Updated to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007101810 Minefield/3.0a9pre without a hang.
I'll try it again using other software.

Comment 4

[Marco Zehe (:MarcoZ)]

Additional places where I see this problem: The dialog that briefly displays when Thunderbird sends a message, the dialog in Thunderbird that asks for password entry for a POP3, IMAP, or SMTP server, and the Download Manager in Firefox also exhibited this once for me.

Comment 5

[Aaron Leventhal]

I think it's one of these bugs:

Bug 388187. Incorrect initial focus event when dialogs are opened. Patch by Ginn Chen, r=aaronlev, a=dsicore

Bug 393660. When non-accessible node is removed/shown, fire events for accessible first-line descendants. Patch put together by both Surkov and aaronlev, r=aaronlev, r=surkov, a=dsicore 

Marco, do you have time to try backing them out separately and see if the bug gets fixed?

Comment 6

[Marco Zehe (:MarcoZ)]

I already tried backing out fix for bug 393660, but that didn't improve the situation. Also, I remember testing bug 388187 before checkin, and that didn't exhibit this particular problem to me, either.

Comment 7

[Aaron Leventhal]

Unfortunately I can't get a crash stack.

1) Can you try to get me the entire crash stack?
2) Can you try once more with bug 388187 backed out again just to make sure? It's the most obvious cause of the problem right now.

Comment 8

[Marco Zehe (:MarcoZ)]

Here's a Stack trace from Thunderbird, after I break it from hanging right after startup:
 	ntdll.dll!7c91eb94() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll]	
 	user32.dll!7e369418() 	
>	thunderbird.exe!nsAppShell::ProcessNextNativeEvent(int mayWait=1)  Zeile 154	C++
 	thunderbird.exe!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=1)  Zeile 137 + 0x11 Bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x02e1da38, int mayWait=1, unsigned int recursionDepth=0)  Zeile 247 + 0xf Bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f9a4)  Zeile 480	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x02e1da38, int mayWait=1)  Zeile 227 + 0x16 Bytes	C++
 	thunderbird.exe!nsBaseAppShell::Run()  Zeile 154 + 0xc Bytes	C++
 	thunderbird.exe!nsAppStartup::Run()  Zeile 170 + 0x1c Bytes	C++
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x02e18df0, const nsXREAppData * aAppData=0x02e1bac8)  Zeile 3142 + 0x25 Bytes	C++
 	thunderbird.exe!main(int argc=1, char * * argv=0x02e18df0)  Zeile 87 + 0x11 Bytes	C++
 	thunderbird.exe!__tmainCRTStartup()  Zeile 597 + 0x19 Bytes	C
 	thunderbird.exe!mainCRTStartup()  Zeile 414	C
 	kernel32.dll!7c816fd7() 	
 	thunderbird.exe!getter_Transfers<Expr>(nsAutoPtr<Expr> & aSmartPtr={...})  Zeile 327 + 0xc Bytes	C++
 	thunderbird.exe!nsBMPDecoder::ProcessData(const char * aBuffer=0x00640047, unsigned int aCount=5242985)  Zeile 602 + 0x1a Bytes	C++
 	thunderbird.exe!getter_Transfers<Expr>(nsAutoPtr<Expr> & aSmartPtr={...})  Zeile 327 + 0xc Bytes	C++
 	thunderbird.exe!nsHTMLEntities::UnicodeToEntity(int aUnicode=6881395)  Zeile 222 + 0x25 Bytes	C++
 	thunderbird.exe!NS_QueryNotificationCallbacks<nsIWebNavigation>(const nsCOMPtr<nsIChannel> & aChannel={...}, nsCOMPtr<nsIWebNavigation> & aResult={...})  Zeile 1130 + 0x12 Bytes	C++
 	75000c7d()	

Comment 9

[Aaron Leventhal]

That's really, really weird. Are you building from a totally clean tree?

Comment 10

[Marco Zehe (:MarcoZ)]

(In reply to comment #9)
> That's really, really weird. Are you building from a totally clean tree?

The tree wasn't totally clean: It contained the patch for bug 397266, but other than that, it was clean.

Comment 11

[Marco Zehe (:MarcoZ)]

Here's another stack trace, updated to latest sources with Thursday's a11y patches in, and no test patches or reverted patches in place.

 	ntdll.dll!7c91eb94() 	
 	[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für ntdll.dll]	
 	user32.dll!7e369418() 	
>	thunderbird.exe!nsAppShell::ProcessNextNativeEvent(int mayWait=1)  Zeile 154	C++
 	thunderbird.exe!nsBaseAppShell::DoProcessNextNativeEvent(int mayWait=1)  Zeile 137 + 0x11 Bytes	C++
 	thunderbird.exe!nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal * thr=0x02e1daa8, int mayWait=1, unsigned int recursionDepth=0)  Zeile 247 + 0xf Bytes	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012f9a4)  Zeile 480	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x02e1daa8, int mayWait=1)  Zeile 227 + 0x16 Bytes	C++
 	thunderbird.exe!nsBaseAppShell::Run()  Zeile 154 + 0xc Bytes	C++
 	thunderbird.exe!nsAppStartup::Run()  Zeile 170 + 0x1c Bytes	C++
 	thunderbird.exe!XRE_main(int argc=1, char * * argv=0x02e18e18, const nsXREAppData * aAppData=0x02e1baf0)  Zeile 3142 + 0x25 Bytes	C++
 	thunderbird.exe!main(int argc=1, char * * argv=0x02e18e18)  Zeile 87 + 0x11 Bytes	C++
 	thunderbird.exe!__tmainCRTStartup()  Zeile 597 + 0x19 Bytes	C
 	thunderbird.exe!mainCRTStartup()  Zeile 414	C
 	kernel32.dll!7c816fd7() 	
 	thunderbird.exe!nsCOMPtr<nsITreeSelection>::assign_from_qi(nsQueryInterface qi={...}, const nsID & aIID={...})  Zeile 1257	C++
 	thunderbird.exe!nsBMPDecoder::ProcessData(const char * aBuffer=0x00540079, unsigned int aCount=7012463)  Zeile 602 + 0x1a Bytes	C++
 	thunderbird.exe!nsHTMLEntities::UnicodeToEntity(int aUnicode=6619211)  Zeile 222 + 0x25 Bytes	C++
 	thunderbird.exe!nsHTMLEntities::UnicodeToEntity(int aUnicode=6619211)  Zeile 222 + 0x25 Bytes	C++
 	thunderbird.exe!nsHTMLEntities::UnicodeToEntity(int aUnicode=6619211)  Zeile 222 + 0x25 Bytes	C++
 	thunderbird.exe!nsHTMLEntities::UnicodeToEntity(int aUnicode=5505145)  Zeile 222 + 0x25 Bytes	C++

Comment 12

[Marco Zehe (:MarcoZ)]

(In reply to comment #7)
> 2) Can you try once more with bug 388187 backed out again just to make sure?
> It's the most obvious cause of the problem right now.

I have done an incremental checkin-by-checkin search starting 6 Oct 2007 at 00:00 PDT, and it turns out that the fix for bug 388187 is indeed the cause of the problem. I tested backing it out earlier, but either it wasn't backed out cleanly, or something else went wrong, it didn't fix the problem back then. But this checkin-by-checkin search updated build reveals that this is indeed the cause.

Comment 13

[Ginn Chen]

I noticed a delay for about 1 second when a dialog shows up with the fix of bug 388187.

Comment 14

[Ginn Chen]

It's possible that FireCurrentFocusEvent() emits focus to the root window, then it's a deadlock.
It's not a hang, but it takes a lot of CPU. 

Comment 15

[Ginn Chen]

Attachment: patch

Comment 16

[Marco Zehe (:MarcoZ)]

I can confirm that this fixes the problem in Thunderbird for me.

Comment 17

[Aaron Leventhal]

Comment on attachment 286542 [details] [diff] [review]
patch

Great fix - excellent work everyone! Nit: you may remove the extra parenthesis in hte |if|.

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 286542 [details] [diff] [review]
patch

a=endgame drivers for M9

Comment 19

[Aaron Leventhal]

Checked in for Ginn.