Closed Bug 171131 Opened 22 years ago Closed 21 years ago

Mozilla gets unstable with system hooks

Categories

(Core :: Security: CAPS, defect)

Product:
Core
Component:
Security: CAPS
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: wvw, Assigned: security-bugs)

References

(
URL
)

Details

(Keywords: crash) 

When using this program, Desktop Manager, Mozilla/NS7/Phoenix gets unstable and
crashes. I don't know if it's the program or Moz, but other programs do not
become unstable. It seems to be related to system hooks, because I experienced
the same behaviour with other system-hooking-utilities (don't know which one,
but I think it was Filebox Extender http://www.hyperionics.com/files/index.asp).
Most of the times the crashing occurs when closing the utility before exiting
Mozilla.
Reporter: Please include a talkback ID with your bug report.
Run talkback.exe after a crash to view the talkback ID assigned to the crash.
For Mozilla 1.1: TB11786660Y (isn't 666 the sign of the devil?), TB11786785K.
For Netscape7: TB 11782205W, 11630922E, 11630905Q. 
Btw. It's always reproducible for me. Just run the Desktop Manager, Mozilla,
close Desktop Manager and open a few new windows in Mozilla. Boom. Crash.
Closing the Manager isn't even always needed for a crash.
stephen, could you get the stacks for the listed talkback IDs?
(those are 11786660Y, 11786785K. or 11782205W, 11630922E, 11630905Q)
Anytime a crash incident ID is over 30 days, it doesn't exist in the Talkback
database.  So, I can't pull anything until I get a fresh incident ID, sorry.
Reporter, are you experiencing this problem with a new build of Mozilla?
Keywords: crash
Yes. 
Talkback id's: TB14890955Z (moz 1.2). TB14891085M (NS7). 

Steps to produce (win 2000):

install this Desktop Manager:
http://www3.nf.sympatico.ca/byronm/dm.html

Start it, Start Moz.

Open up some new windows in moz, switch desktops in the manager. repeat until it
crashes.

It has something to do with hooks, I'm sure. It must also be something in DM,
because it only occurs with the program, but Moz/NS7/Phoenix are the only
programs crashing with it, I tried several other programs.
Keywords: stackwanted
Whiteboard: TB14890955Z
stephen: we've got a new TB ID here, could you get it?
(TB14890955Z) (or TB14891085M  if that doesn't work)
JS_GetFrameFunctionObject [c:/builds/seamonkey/mozilla/js/src/jsdbgapi.c, line 735]
nsScriptSecurityManager::GetFramePrincipal
[c:/builds/seamonkey/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1835]
nsScriptSecurityManager::GetPrincipalAndFrame
[c:/builds/seamonkey/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1855]
nsScriptSecurityManager::GetSubjectPrincipal
[c:/builds/seamonkey/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1895]
nsScriptSecurityManager::GetSubjectPrincipal
[c:/builds/seamonkey/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1607]
nsScriptSecurityManager::SubjectPrincipalIsSystem
[c:/builds/seamonkey/mozilla/caps/src/nsScriptSecurityManager.cpp, line 1635]
GlobalWindowImpl::CheckSecurityIsChromeCaller
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2113]
GlobalWindowImpl::IsCallerChrome
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2127]
GlobalWindowImpl::Focus
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2370]
nsEventStateManager::PreHandleEvent
[c:/builds/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp, line 698]
PresShell::HandleEventInternal
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6241]
PresShell::HandleEvent
[c:/builds/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp, line 6169]
nsViewManager::HandleEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2163]
nsView::HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 304]
nsViewManager::DispatchEvent
[c:/builds/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1949]
HandleEvent [c:/builds/seamonkey/mozilla/view/src/nsView.cpp, line 83]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1073]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1090]
nsWindow::DispatchFocus
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5479]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4155]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1339]
USER32.DLL + 0x1b60 (0x77e11b60)
USER32.DLL + 0x2f29 (0x77e12f29)
USER32.DLL + 0x2f4f (0x77e12f4f)
ntdll.dll + 0x2032f (0x77fa032f)
GlobalWindowImpl::Focus
[c:/builds/seamonkey/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2400]
nsWebShellWindow::HandleEvent
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsWebShellWindow.cpp, line 612]
nsWindow::DispatchEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1073]
nsWindow::DispatchWindowEvent
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1090]
nsWindow::DispatchFocus
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 5479]
nsWindow::ProcessMessage
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 4149]
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1339]
USER32.DLL + 0x1b60 (0x77e11b60)
USER32.DLL + 0x2f29 (0x77e12f29)
USER32.DLL + 0x2f4f (0x77e12f4f)
ntdll.dll + 0x2032f (0x77fa032f)
USER32.DLL + 0x4c17 (0x77e14c17)
USER32.DLL + 0x1b60 (0x77e11b60)
USER32.DLL + 0x42eb (0x77e142eb)
USER32.DLL + 0x4ce5 (0x77e14ce5)
nsWindow::WindowProc
[c:/builds/seamonkey/mozilla/widget/src/windows/nsWindow.cpp, line 1360]
USER32.DLL + 0x1b60 (0x77e11b60)
USER32.DLL + 0x2f29 (0x77e12f29)
USER32.DLL + 0x2f4f (0x77e12f4f)
ntdll.dll + 0x2032f (0x77fa032f)
USER32.DLL + 0x29ff (0x77e129ff)
nsAppShell::Run [c:/builds/seamonkey/mozilla/widget/src/windows/nsAppShell.cpp,
line 173]
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 472]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1557]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1905]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1925]
WinMainCRTStartup()
KERNEL32.DLL + 0xd326 (0x77e8d326) 
wow, that stack looks ugly... 

-> JS Debugger, given this is in js/src/jsdbgapi.c... cc'ing brendan in case
this file is JS Eng, rather than JS Debugger.
Assignee: asa → rginda
Component: Browser-General → JavaScript Debugger
Keywords: stackwanted
QA Contact: asa → caillon
Whiteboard: TB14890955Z
js/src/ is the js engine, js/jsd/ is the debugger.  I doubt this is a js engine
bug though.  Most likely something earlier in the call stack (security) is
getting confused and passing a null frame to the js engine.
Component: JavaScript Debugger → Security: CAPS
CAPS owner.

/be
Assignee: rginda → mstoltz
Critical severity.
Severity: major → critical
Blocks: 185584
No longer blocks: 185584
I am unable to reproduce this with the current build and current Desktop
manager.  Reporter could you please try to create another testcase?  I ran both
programs together for about 5 minutes and was unable to get anything untoward to
happen.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040114

is what I was testing with.

Also, this bug is getting pretty old - it may have been fixed somewhere along
the way in either app.
It indeed is not happening anymore, I can confirm.
-> WFM
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
reopen resolution and comment don't match
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
This time for real.
(per reporter's comment)
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.