485680 - crash [@ js_LookupPropertyWithFlags] closing RSS window w/enigmail installed

Status: RESOLVED WORKSFORME

(MailNews Core :: Feed Reader, defect)

Description

[Joshua J. Drake]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)
Build Identifier: version 2.0.0.21 (20090302)

When the Enigmail addon is present, closing an RSS article window causes a crash with a DEP warning.  Message pane must be disabled.

Reproducible: Always

Steps to Reproduce:
1. Install Thunderbird
2. Choose "RSS News & Blogs" for the account
3. Install Enigmail add-on (0.95.7)
4. Subscribe to the nasty feed (do not use article summary mode)
5. Disable message pane
6. navigate to the feed & open the article
7. click the close box prior to the article finishing loading (while busy)
8. crash!
Actual Results:  
Crashed!

Expected Results:  
Closed the window gracefully, as it does w/o the Enigmail plugin or when one stops the loading prior to closing the window...

Comment 1

[Joshua J. Drake]

NOTE: the URL for the test feed is above in the header area..

Comment 2

[Ludovic Hirlimann [:Usul]]

(In reply to comment #0)
> Expected Results:  
> Closed the window gracefully, as it does w/o the Enigmail plugin or when one
> stops the loading prior to closing the window...

Can you provide crash IDs as described here :
http://kb.mozillazine.org/Talkback

Comment 3

[Joshua J. Drake]

TB53764509Q

Comment 4

[Ludovic Hirlimann [:Usul]]

js_LookupPropertyWithFlags  [mozilla/js/src/jsobj.c, line 3260]
js_LookupProperty  [mozilla/js/src/jsobj.c, line 3187]
js_GetProperty  [mozilla/js/src/jsobj.c, line 3566]
nsXPCWrappedJSClass::CallQueryInterfaceOnJSObject  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 243]
nsXPCWrappedJSClass::DelegatedQueryInterface  [mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 633]
nsXPCWrappedJS::QueryInterface  [mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 106]
nsEventListenerManager::HandleEvent  [mozilla/content/events/src/nsEventListenerManager.cpp, line 1752]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2237]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2216]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2216]
nsXULElement::HandleDOMEvent  [mozilla/content/xul/content/src/nsXULElement.cpp, line 2216]
PresShell::HandleEventInternal  [mozilla/layout/base/nsPresShell.cpp, line 6542]
PresShell::HandleEvent  [mozilla/layout/base/nsPresShell.cpp, line 6377]
nsViewManager::HandleEvent  [mozilla/view/src/nsViewManager.cpp, line 2566]
nsViewManager::DispatchEvent  [mozilla/view/src/nsViewManager.cpp, line 2253]
HandleEvent  [mozilla/view/src/nsView.cpp, line 174]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1319]
nsWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6329]
ChildWindow::DispatchMouseEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 6576]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1507]
USER32.dll + 0x18807 (0x76468807)
USER32.dll + 0x18962 (0x76468962)
USER32.dll + 0x18aad (0x76468aad)
USER32.dll + 0x18b00 (0x76468b00)
nsAppShell::Run  [mozilla/widget/src/windows/nsAppShell.cpp, line 159]
nsAppStartup::Run  [mozilla/toolkit/components/startup/src/nsAppStartup.cpp, line 152]
main  [mozilla/mail/app/nsMailApp.cpp, line 62]
kernel32.dll + 0x8e3f3 (0x769ae3f3)
ntdll.dll + 0x7cfed (0x7704cfed)
ntdll.dll + 0x7d1ff (0x7704d1ff)

Comment 5

[Daniel Veditz [:dveditz]]

Duping this one, that has details about how to reproduce, to a bug based on seeing a common talkback doesn't seem very useful. They may or may not be the same (seems unlikely there are enough enigmail users to cause a topcrash). There are at least five previously fixed bugs that crash at this location, four of them fixed on the 1.8.1 branch so clearly "crashing at the same place" doesn't mean it's the same bug when it's in the guts of the javascript engine. The corruption is happening elsewhere, setting landmines for the engine to trip over.

If this is triggering a DEP warning it's doing something potentially abusable, don't know why the security flag was removed.

Comment 6

[Daniel Veditz [:dveditz]]

Confirming based on comment 4.

This is the fixed query I referred to in the previous comment
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20js_LookupPropertyWithFlags

Comment 7

[Joshua J. Drake]

It might be worth trying to run Thunderbird with page heap turned on.  I just tried and it crashed inside the RSS reader during normal use.  That's not a very comforting behavior...

Comment 8

[Ludovic Hirlimann [:Usul]]

(In reply to comment #7)
> It might be worth trying to run Thunderbird with page heap turned on.  I just
> tried and it crashed inside the RSS reader during normal use.  That's not a
> very comforting behavior...

do you have a TB ? (does this also happen in TB3 ?)

Comment 9

[Wayne Mery (:wsmwk)]

Patrick, is there any reason to believe this may be fixed by a newer version of enigmail?

Joshua, can you reproduce this using your comment 0 steps, with v3 beta, which is being finalized for release? You'll need an updated enigmail. backup your profile before testing. Be aware that this release will change your UI. but the install will not remove your Thunderbird 2.
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/

Comment 10

[Joshua J. Drake]

(In reply to comment #9)
> Patrick, is there any reason to believe this may be fixed by a newer version of
> enigmail?
> 
> Joshua, can you reproduce this using your comment 0 steps, with v3 beta, which
> is being finalized for release? You'll need an updated enigmail. backup your
> profile before testing. Be aware that this release will change your UI. but the
> install will not remove your Thunderbird 2.
> http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.1/

enigmail will not install with a 3.0 version. 

furthermore, the directions no longer work due to changes in the usage flow. the article no longer appears to render properly unless you choose "open in a new window". "open in a new tab" or double-clicking it only shows the article title.

on a positive note, tb3 now runs with page heap turned on without crashing horribly during normal use.

Comment 11

[Ludovic Hirlimann [:Usul]]

(In reply to comment #10)
> (In reply to comment #9)
> enigmail will not install with a 3.0 version. 

The nightly builds works like a charm on tB3.

Comment 12

[Patrick Brunschwig]

(In reply to comment #9)
> Patrick, is there any reason to believe this may be fixed by a newer version of
> enigmail?

Sorry, I must have missed your question at 1st. I didn't change anything in this so I doubt that a newer version of Enigmail would have fixed this.

Comment 13

[Joshua J. Drake]

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > enigmail will not install with a 3.0 version. 
> 
> The nightly builds works like a charm on tB3.

Okay, I tried with the nightly build of enigmail/tb3. It didn't crash when closing a busy window that was created opening an article with 'open in a new window'.

Comment 14

[Wayne Mery (:wsmwk)]

none of the recent trunk/3.0 crashes list enigmail as being loaded, so marking this bug ver=1.8.1

Comment 15

[Jesse Ruderman]

Let's just call this WFM, since that's such an old branch.