366691 - Thunderbird crashes while restoring from minimized view [@ JS_GetScriptPrincipals]

Status: VERIFIED DUPLICATE of bug 349171

(Core :: JavaScript Engine, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060831 Thunderbird/2.0a1 Mnenhy/0.7.4.0 ID:2007011004

Thunderbird was running in minimized view for a longer period of time. When I clicked the button on the task bar Thunderbird crashed. There are a lot of other crashes also for Firefox 2.0.0.1.

Talkback: TB28255850G 

Stack Signature	 JS_GetScriptPrincipals 494bb94d
Product ID	Thunderbird2
Build ID	2007011004
Trigger Time	2007-01-11 08:08:10.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	js3250.dll + (0000f6ac)
URL visited	
User Comments	Thunderbird crashed while restoring from minimized view
Since Last Crash	26086 sec
Total Uptime	26086 sec
Trigger Reason	Access violation
Source File, Line No.	e:/builds/tinderbox/Tb-Mozilla1.8/WINNT_5.0_Depend/mozilla/js/src/jsdbgapi.c, line 712
Stack Trace 	
JS_GetScriptPrincipals  [mozilla/js/src/jsdbgapi.c, line 712]
nsScriptSecurityManager::GetPrincipalAndFrame  [mozilla/caps/src/nsScriptSecurityManager.cpp, line 2077]
nsScriptSecurityManager::GetSubjectPrincipal  [mozilla/caps/src/nsScriptSecurityManager.cpp, line 2119]
nsScriptSecurityManager::doGetSubjectPrincipal  [mozilla/caps/src/nsScriptSecurityManager.cpp, line 1717]
nsScriptSecurityManager::SubjectPrincipalIsSystem  [mozilla/caps/src/nsScriptSecurityManager.cpp, line 1752]
nsGlobalWindow::IsCallerChrome  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 3260]
nsGlobalWindow::CanSetProperty  [mozilla/dom/src/base/nsGlobalWindow.cpp, line 4187]
nsWebShellWindow::HandleEvent  [mozilla/xpfe/appshell/src/nsWebShellWindow.cpp, line 501]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nsWindow.cpp, line 1389]
nsWindow::DispatchFocus  [mozilla/widget/src/windows/nsWindow.cpp, line 6621]
nsWindow::ProcessMessage  [mozilla/widget/src/windows/nsWindow.cpp, line 5313]
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1577]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0xd05b (0x77d1d05b)
USER32.dll + 0xb4c0 (0x77d1b4c0)
USER32.dll + 0xd0a5 (0x77d1d0a5)
ntdll.dll + 0xeae3 (0x7c91eae3)
USER32.dll + 0xb3f9 (0x77d1b3f9)
uxtheme.dll + 0x3c20 (0x5b0f3c20)
uxtheme.dll + 0x1e300 (0x5b10e300)
uxtheme.dll + 0x1ac7 (0x5b0f1ac7)
uxtheme.dll + 0x1b3d (0x5b0f1b3d)
USER32.dll + 0xbb15 (0x77d1bb15)
nsWindow::DefaultWindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1603]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0x8816 (0x77d18816)
USER32.dll + 0xc63f (0x77d1c63f)
USER32.dll + 0xc665 (0x77d1c665)
nsWindow::WindowProc  [mozilla/widget/src/windows/nsWindow.cpp, line 1584]
USER32.dll + 0x8734 (0x77d18734)
USER32.dll + 0x8816 (0x77d18816)
USER32.dll + 0x89cd (0x77d189cd)
USER32.dll + 0x8a10 (0x77d18a10)
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 + 0x16fd7 (0x7c816fd7)

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Top crasher list:

App            Rank      %  Total Open Bugs Fixed Bugs Lin Mac Win
Fx 1.5.0.9      160  0.06%     45                               45
Fx 2.0.0.1      220  0.04%     55                               55
Tb 1.5.0.9      141  0.06%     13                               13
Tb (Branch 1.8)  32  0.58%      1                                1 			

Comment 2

[timeless]

you did a really good job of searching for obvious duplicates before filing. come on.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hey, why this should be a dupe of bug 349171? It's the same module, ok. But the stack signature is totally different. Bug 279678 handles JS_GetFrameFunctionObject thats really not visible for my stack trace! 

Comment 4

[timeless]

The signature for the crash is: Crashing in js3250 from nsGlobalWindow::IsCallerChrome with no js on the stack beneath that call.

alternatively, this bug has virtually the exact same summary as that bug.

They're also tagged as topcrashes, so at the very least a basic search for things should have turned them up and you should have asked if they were the same or related.

Comment 5

[Brendan Eich [:brendan]]

Timeless, ease up, man -- it's not obviously the same signature.  Is the lack of any JS on the stack really enough to say this is the same bug?  I don't know, so I don't see how everyone should be expected to think so.

Anyway, dups happen.  Be nice.

/be

Comment 6

[timeless]

i've lived with this bug for about 6 years. and it's trivial for people to ask about bugs. it's trivial for people to read topcrash bugs. at the very least, a bug with a nearly identical summary should be investigated:
(product: thunderbird) crash on restore minimized instance

frames 2.. all match. and people by now should know not to blame the top frame in all crashes, especially when the frames are ones such as these (innocuous and in long standing modules).

besides, who are you to complain, you would have yelled at him (and have yelled at others before) for filing this bug in javascript for the reasons i mention above.

Comment 7

[Brendan Eich [:brendan]]

Timeless, maybe we should take this to private email. If I've been less than nice in the past, it's my fault. I apologize for any such wrath directed your way. It is not your charter to do likewise.

/be

Comment 8

[Brendan Eich [:brendan]]

Another question: is the top frame different because of code changes, or something determistic that we understand? Sometimes the top frame differing *does* mean the bugs are distinct.

Another point on bug etiquette: new members of the community can't be expected to do as well as seasoned pros at identifying dups. Please take that into account if it applies here.

/be

Comment 9

[timeless]

it doesn't. from my experience, the slightly different signatures happened with about equal regularity and not always the same signature each time.

ignoring the fact that only experienced people know and should be using the topcrash keyword or know how to use and should be using or filing bugs based on talkback reporting (not incidents, *reporting*!). he's from 2003 (granted, i was playing w/ this crash 1-2 years before that, but, that doesn't make him unseasoned).

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Thank you for all the comments timeless. You are the perfect human who never makes mistakes (what I can see when watching your dupe list). A community is living by it's members, whatever if they are new or long standing contributors. Everyone is trying to help as good as he can. You should respect this. If you are frustrated then try to solve it somewhere else. It will interfere the teamwork.

Ok, I missed the bug of Mike. It's my fault. I was looking at the talkback reports for my top frame. Due to there was listed no open bug for this I searched bugzilla (subject and comments) for the top frame. But nothing was found. From now on I will expand the search to the next frames until I find a result (or not). Is there a maximum number of frames you should step back until filing a new bug report?

Comment 11

[timeless]

you should of course search by summary if you have one, advanced search has for over a year (and best practices for much longer) been to search duplicate bugs too. that would have been sufficient here.

general rules while hunting topcrashers:
0. keep in mind that a topcrash can very easily not have the signature you're looking for, searching by description if you have one is important. this is especially true as people get more annoying and start hiding crashes in attachments.
1. check frames 0, 1 and 2.
2. if the top frame is a hex value, or an ntdll or some other stable module (nspr, js3250, msvcrt, msvcr, ...) check the next module's last frame. just because talkback lumps all crashes in [@ free] as the same doesn't mean they are, and while searching you need to check the frame for the calling module. note that you should repeat this for multiple modules. if ntdll is the top module and msvcrt is the next module, you'd repeat the process checking the following module. the same would apply here, js and caps are both relatively stable and haven't changed significantly in 7 years. so in this case you'd want to check nsScriptSecurityManager::GetPrincipalAndFrame and nsGlobalWindow::IsCallerChrome. note that nsScriptSecurityManager::GetPrincipalAndFrame would have found the crash.